C++/SDL Game Design Guidance

[firey]

I posted this over on gamedev.net but haven't had any hits yet, hoping some of the bright minds here can give me some guidance.

I have started working on writing a 2D Isometric style game. The idea is to have a persistant world (each tile is unique) and sent from the server where it is then generated (tile object) and then drawn when needed.

The way the game code works right now is that all objects have Draw() and Update() functions that are called every loop by it's parent "Screen" (Static objects, with their own controls/objects/references) Draw() and Update() functions, which in turn are called during the game loop. Basically:

While (!Exited)

ActiveScreen->Update(); -> In turn updating all child objects

ActiveScreen->Draw(); -> In turn drawing all the child objects

While our FPS > Max wait

Inside the Update() functions are things such as positioning, reloading certain objects I free to prevent leaks, checking sdl events (mouse movements, key presses, etc).

Then the Draw() functions determine if that object is visible on the screen, if it is marked visible, if the texture is valid, etc then it runs the SDL Functions to draw it (blit).

The screens Draw() function first clears the screen, runs all the draw functions for the objects that have been programmed then it refreshes the screen so that the changes are visible.

First question, is the above the right concept? I used things I had read/sdl tutorials/way XNA did things to put that bit together. If anyone has a better suggestion I am all ears.

Second question, even though I have the checks to ensure that things show on screen I notice that with a large tile array it slows right down even though it is only displaying a small portion, should I have an array that is filled on the update function that holds all the tile objects instead of looping through all of them at draw time? As each tile is it's own thing and done isometrically I need to redraw each visible tile every time so that they stack properly, so updating only 1 tile at a time isn't doable as it will end up overlapping in the wrong way.

I am sure I will have more questions as I go along. I am pretty experienced with C# and I understand C++ enough to make it work/work right however I am not that well versed in game logic as I do application programming for a living. I want to do this in C++ with SDL instead of using a pre-built solution (XNA,MonoGame,etc) as this will teach me a lot more than using things I am already comfortable with, and a lot of the logic is already handled in.

[Karl L.]

I don't have any professional experience with game development, but I have often found it helpful to look at other's source code to see how things are done. I have learned a lot about various programming languages and frameworks that way.

Maybe it would help if you traced through Raven's Jedi Academy source. It is written in C++ and makes use of SDL, just like your game. You might also consider looking at the Ioquake3 source code because it also uses the Quake 3 engine. Effectively, the code is similar because they are both based on the same engine, but ioquake3 has many more features and bug-fixes since Quake 3 has been open-source for much longer.

[firey]

Thanks for those links :)

I am definitely not well versed in game programming, and haven't really had to control things 100%. With .NET 90% of the stuff is already done for me. The one suggestion I have received so far from gamedev was to use space partitioning (treat multiple objects as 1 group and treat them all the same).

This is what I posted in response.

Yea right now I do something like the following for drawing the tiles for example

In gamescreen.cpp's Draw() function

if (ActiveMap != NULL {

ActiveMap->Draw();

}

Active Map's Draw Function()

for (int i = ; i < Tiles.size(); i++) {

if (Tiles[i]->XDrawPos() > -140 && Tiles[i]->XDrawPos() < Client::ActiveWindow->Width &&

Tiles[i]->YDrawPos() > -140 && Tiles[i]->YDrawPos() < Client::ActiveWindow->Height) {

Tiles[i]->Draw();

}

}

Tiles Draw() Is basically just an SDL_Blit of the tile rect on the games sdl_surface at the X/Y Draw position.

I'm not entirely sure on how to grid it, unless I do x > X and x < Z = Group 1 and if pos > X and < Z then draw Group 1. Because I would essentially draw 4 grids each time (as you could be halfway between one and another). Doing this would put 90% of the processing as part of the world loading. However I plan on getting tile info from the server which means I will still need to do processing as I load a tile block.

The drawing of the tiles is where I notice the slow down, if I don't have it drawing tiles/large number of tiles it runs fine. Also, with the other visiblity I just use a boolean inside the object ie)

TextboxLogin->Visible = true/false

And in the draw I just do an

if (Visible) {

Draw it;

}

[Xilo]

A good way to get more performance is to only draw portions of the screen that have changed. Drawing only visible objects is another.

[firey]

A good way to get more performance is to only draw portions of the screen that have changed. Drawing only visible objects is another.

I currently have properties with X and Y position which is offset by the camera, to which I only draw the objects inside the view port, I also have a Visible boolean which I can specify to draw or not. I was considering redrawing just portions, but the way I have the tiles I have to redraw them all. An option I could do, is separate the tile and edge graphics and only draw the side (edge graphics) on the map edge, then only redraw specific tiles (if a character is overlapping it and moves/other sprite interacts). I could have an isdirty option or something.

[Andre S. Veteran]

Unless you're rendering tens of thousands of sprites, if performance is an issue then your drawing code is just plain inefficient. Even crappy integrated graphics can render a lot of sprites without issues if done properly. I'm not familiar with SDL so I don't know how well it performs. Does it use OpenGL acceleration to draw 2d graphics? XNA has a SpriteBatch object that batches draw calls sorted by texture to optimize performance; perhaps there is some similar functionality in SDL - or you'll have to implement it yourself.

Your idea of having every object have a draw and update method is very similar to XNA's basic architecture, however feel free to break from this model as needed. Not every object should be drawable, and not every object should be updated every tick either. I personally tend to have only high-level classes (managers) have an update() method, and sometimes draw if they're responsible for drawing something (like the UI manager or terrain renderer). It's important to maintain a healthy level of separation between gameplay logic and rendering.

[firey]

Unless you're rendering tens of thousands of sprites, if performance is an issue then your drawing code is just plain inefficient. Even crappy integrated graphics can render a lot of sprites without issues if done properly. I'm not familiar with SDL so I don't know how well it performs. Does it use OpenGL acceleration to draw 2d graphics? XNA has a SpriteBatch object that batches draw calls sorted by texture to optimize performance; perhaps there is some similar functionality in SDL - or you'll have to implement it yourself.

Your idea of having every object have a draw and update method is very similar to XNA's basic architecture, however feel free to break from this model as needed. Not every object should be drawable, and not every object should be updated every tick either. I personally tend to have only high-level classes (managers) have an update() method, and sometimes draw if they're responsible for drawing something (like the UI manager or terrain renderer). It's important to maintain a healthy level of separation between gameplay logic and rendering.

I am not rendering that many, at most maybe.. 200 sprites (including the tiles). And the game slows right now. I am not sure how SDL Does it, but as far as I know it does have HWA. I am assuming my drawing code is inefficient but I am not sure how.

I tried to follow how I would do it in XNA (Update/Draw) functions. I will do the following on a draw:

Clear Screen

Draw Nameplates/Portraits

Draw World Tiles

Draw NPCS/Characters top -> bottom (proper layering)

Draw Any Text/Speech

Draw the GUI Controls

I use the update mostly for applying settings/determining if something should be visible or not. Pretty much everything has an update (in the way I am doing it), but the updates are more for applying the font/positioning the font for rendering.

Right now game logic is done primarily through the update procedures and with function calls.

The Rendering/Drawing is more or less the application of the updates. It is essentially a graphical snapshot of what the updates say is happening.

Also, on a side note the memory management is pretty good, using pointers to objects lets me have 3000+ tiles and use pretty much the exact same memory.

[Veiva]

Which version of SDL are you using? Are you positive you're using hardware acceleration? What resolution are you targeting?

I know from experience using Allegro there's two rendering paths [in Allegro]: software (very slow) and hardware acceleration (very fast). Allegro 4.x used software while Allegro 5.x uses hardware acceleration. I believe the same could be said for SDL, but I'm not experienced with SDL outside of using it just for OpenGL context creation.

[firey]

Which version of SDL are you using? Are you positive you're using hardware acceleration? What resolution are you targeting?

I know from experience using Allegro there's two rendering paths [in Allegro]: software (very slow) and hardware acceleration (very fast). Allegro 4.x used software while Allegro 5.x uses hardware acceleration. I believe the same could be said for SDL, but I'm not experienced with SDL outside of using it just for OpenGL context creation.

SDL 1.2 at first I think I was using SW (SW_SURFACE) read about using HW_SURFACE going to try it and see what it does. But as far as I know it does have HWA (which is the main reason I chose it).