Skip to main content
gamedev.net
🔒 Locked

2D engine Optimizations

Started by vulh102 Jan 3, 2007 at 8:07 AM 6 replies 1.2k views
Original Post
vulh102
vulh102
ooooook.... well, as everybody else im gonna develop an engine (this will be like my... fifth, sorta ) whats different this time though is that im planning ahead, ive made a pretty nice UML diagram, and some research. Now, i have some ideas of optimizations, that i quite cant find an answer to. so here goes Question 1 Im gonna use vertex arrays and point sprites for graphics. as you cant rotate a point sprite i thought of using a vertex shader that rotates the texture coordinates. the size of the sprite needs to come with also this rotation and size needs to find its way to the GPU. i have come up with some ideas of doing so, please review them. 1. Using an vertex array that stores the rotation and size as a float (Dunno if this is doable) 2. in case the first isnt allowed, use another list that i dont need, like texcoords to describe the rotation and size 3. dont use vertex arrays at all, instead use a reusable display list 4. dont do the engine at all, and drink tea Question 2 currently the engine will be using 2 standard threads, one for the simulator. and one for the renderer. I need to have a simulator because i want it to be deteremistic, in case i want to expand it with some networking. does anyone know the overhead and cpu strain of a thread? im also wondering how you people would solve the data stream between the renderer and the simulator as of now, the renderer will pull a current state from the simulator the current state will include the data that i described in question 1 Question 3 i will probably not be able to resist the urge of network in this engine, still, creating good network code is tiersome and pretty hard work. so. is there a network lib out there that uses UDP and guarantees most of the following 1. guranteed package delivery 2. not guaranteed package delivery 3. packages in correct order 4. c++ driven 5. easy clean interface that wont make my code dirty well thats that im would also be glad if you post some other tips for me ( and some cheers would be nice) Happy codin!
Bob Janova
Bob Janova
Question 1: sorry, not my department ;).
Question 2: threads do have a small cost, but just having one extra thread won't hurt you noticably. On new dual-core systems it's likely to actually get a performance gain if used well. Over-threading is only an issue if you start having one per player or something.
Question 3: I think there are several links in the FAQ for the Multiplayer and Networking forum.
OrangyTang
OrangyTang
Some thoughts:
1. I wouldn't bother with point sprites, as they make rotation practically impossible (if you rotate the texture coords, you loose the ability to pack multiple sprites into sprite sheets / texture atlases). I'd just use quads and do the rotation on the CPU or GPU (I'd do it on the CPU, as IMHO a 2d engine should run on shader-less hardware).

2. There are better ways to decouple logic rate and rendering rate. Have a look in the forums and you'll find lots of info. IMHO two threads is a bad idea, you'll just introduce lots of awkward, subtle and difficult to replicate bugs with no real gain.
ViperG
ViperG
I'd recommend using a graphics api like opengl or directx which handles the rotations on the gpu. Plus you will get the hardware benefits of 3d.
Black Sky A Star Control 2/Elite like game
Donyc
Donyc
Question 3: Check if RakNet (http://www.rakkarsoft.com/) is suited for your purpose.
"There's always one more bug"My blog
LorenzoGatti
LorenzoGatti
Quote:
Original post by OrangyTang
Some thoughts:
1. I wouldn't bother with point sprites, as they make rotation practically impossible (if you rotate the texture coords, you loose the ability to pack multiple sprites into sprite sheets / texture atlases). I'd just use quads and do the rotation on the CPU or GPU (I'd do it on the CPU, as IMHO a 2d engine should run on shader-less hardware).


I agree completely, but two obvious variations come to mind:
1) Textured triangles: 3/4 of the vertices, cheaper to process, but packing sprites into large textures might be more difficult or wasteful (lots of transparent corners), and an increase of transparent fragments (for said transparent corners) is likely.
2) Splitting the quads in half, issuing two triangles with an edge in common.

I think these three texture mapping approaches are similar enough, and their performance differences uncertain enough, to deserve being benchmarked against each other.
Omae Wa Mou Shindeiru
OrangyTang
OrangyTang
Quote:
Original post by LorenzoGatti
1) Textured triangles: 3/4 of the vertices, cheaper to process, but packing sprites into large textures might be more difficult or wasteful (lots of transparent corners), and an increase of transparent fragments (for said transparent corners) is likely.

Any non-trivial 2d game is going to be fillrate limited IMHO, and while you might reduce the vertex count you're increasing the fillrate used quite a bit. I don't think this is a good approach.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.