Messages

1

SFML projects / Re: Singularity pre-alpha (WIP)

« on: January 05, 2014, 10:21:14 am »

Purely text based for the forseeable future, but I'm not against adding simple graphics where appropriate. Maybe dressing to separate content on busy screens. Maybe when certain events are triggered they are shown as a fake web page. Maybe an overlay to show where the buttons are instead of changing text colour.

2

SFML projects / Singularity pre-alpha (WIP)

« on: January 04, 2014, 06:45:00 pm »

It'll probably never come to anything, but I made an intro for a game I'm thinking about doing. The basic idea is that you're a sentient ai created by chance, and you have to do what you can to survive (inspired by this game: http://www.emhsoft.com/singularity/ ). The graphics emulate a terminal by using a custom font stored in an image, drawn character by character. In the end I want the ui to be keyboard and/or mouse, probably with the clickable text (aka buttons) a different colour, with the keyboard shortcuts a different different colour.

1080p to more easily see the graphics.


I have a basic idea for a storyline, where you have to advance beyond human's ability to destroy you before you're discovered. Any number of events could be involved which could help or hinder you. Main storyline events would be inevitable (possibly delayable), but others can be manipulated, instigated, mitigated or avoided altogether. Gameplay would involve maintaining resources (compute power and money), researching (advancement, new abilities) and taking action (using abilities). Literally none of that is done, just what is in the video. The rest is what I plan to do until something shiny distracts me

3

Graphics / Re: Optimise drawing, beyond using VertexArray?

« on: November 23, 2013, 04:15:00 pm »

...
To reduce geometry processing load, you can try to cull what can't be seen anyway in a culling pass on the CPU before sending it to the GPU.
...

Off-screen culling is done naturally already, the view is static and objects are destroyed when they move offscreen. This should account for 98% of what can be culled. The bullets should be on the top layer to stop 'invisible deaths', so the only thing to obscure bullets are other bullets. There are some fringe cases that could possibly benefit from extra culling, will investigate.

...
You could write a VBO implementation using OpenGL for sending it once to GPU and then only let it do the processing each frame, but if you would change much of the data each frame it may not help.
...

All of the position data changes each frame. Most bullets follow a predictable straight trajectory, some (not many) are axis-aligned so only x or y needs to be updated. I don't think this fulfills your criteria? Can't test it yet due to lack of skill.

Thank you for the informative replies. Raw opengl is a little beyond me without being a massive rabbit-hole timesink, but when I get more familiar with the api I'll give it a go. Before I get into opengl I'm going to try implementing some cheats to minimise bullet count for the engine (like a bigger bullet that looks like a cluster of smaller bullets).

4

Graphics / Optimise drawing, beyond using VertexArray?

« on: November 23, 2013, 11:48:54 am »

I'm trying to optimise drawing to maximise the number of objects that can be drawn using the same texture. Here's the code:

Code: [Select]

      //draw single bullet type
      sf::RenderStates states;
      states.texture = &tex[bullet_type];
      window[0].draw(&vertex_arr[0], num_to_draw*4, sf::Quads, states);
Details:

• Converted from Sprites to VertexArray
• Minimise primitive/texture size so there's less pixels to blit
• vertex_arr has position and texCoords set, color is not used/altered
• Texture is 32-bit, but could use a reduced form of 1-bit alpha and small color palette rgb

Is there a next step to speed things up? For testing I'm drawing 1,000,000 7x7 objects per frame (whether the texture is 7x7 or 8x8 makes little difference). Currently at ~4FPS, the above draw call takes the majority of the time. I don't need it to be quick enough to draw 1,000,000 objects per frame, realistically objects will be measured in the thousands (bullet hell shmup, say 10k as a high upper ceiling), but my logic is the quicker it can be made the older the hardware that can be supported. As a shmup the game uses a fixed timestep with framerate capped at 60FPS.