Getting together for developing a Game?


I actually dont know how the rendering should be handled, since there wont be a ton of polygons I think drawing them individually is perhaps not a problem. It might also be possible to add several bmp images into one big sheet and just use offset coordinates for drawing all polygons with different textures in one single go. That could gain performance possibly.


I should be able to create a function that draws like you described anyway.


drawTexture(texWidht, texHeight, posX, posY, texNumber, rtotateAngle, scaleSize);


texWidht and Height is size of polygon, posX and Y is to place it either in world space coordinates or in screen space coordinates. texNumbaer is wich created texture to bind for use, rotation and scaling. posX can be center of poly or any corner.
 
Here's a very quick GLBasic example of a 2 layer (+blank background) parallax scrolling level running at a limited 30FPS with ship control and a single large rotating enemy. This example creates a huuuuuge random scrolling level (approx. 80 screenwidths wide). The actual program runs at over 45FPS (sorry I can't get steady 60FPS - maybe with less parallax).


I've not put it into a true .PND file, but you can run it from it's folder (unzip it and place the parallax_scroller folder into the apps folder on your SD card). Select "2" on the options screen. Move ship with cursors.


Option 1 just scrolls the landscape with cursors - uses a different rendering engine to 2 (a bit slower).


Option 3 doesn't work properly on Pandora but does on pc - it's more efficient/smoother than option 2 but takes about a second to set-up the level. not sure why it works on pc and not Pandora though :(


GLBasic may not be as fast as native C++ but development and testing is certainly quicker and it gives access to real-time scaling and rotations plus alpha imaging etc.

parallax_scroller.zip
 

Attachments

  • parallax_scroller.zip
    369.3 KB · Views: 138
Here's a simple parallax scroller in C/SDL. If anybody has their Pandora handy (mine's at home), could they check the FPS (Window title). You can also press the "A" key to switch on alpha blending, and check if it drops the FPS any.


Escape quits

ParallaxCheck.zip
 

Attachments

  • ParallaxCheck.zip
    11.9 KB · Views: 165
it runs at roughly 25FPS (mainly 23-25FPS but sometimes drops to 17) without alpha and around 20FPS with alpha.


Running on Super Zaxxon Final at 600MHz.
 
Really? That's s**t... Though it might be because I've double buffered. Here's the code I used.


Edit: How can so little really only give 25FPS? Could this be something to do with my build? It worries me that I see lots of complicated code run really fast, but something which is litterally blitting 4 times is so slow!?

Code:
#include <SDL.h>


int main( int argc, char* argv[] )

{

    int running = 1;

    SDL_Surface* display;

    SDL_Event e;

    SDL_Surface* parallax[2];

    int parallaxX[2];

    SDL_Rect s;

    SDL_Rect d;

    int alpha = 0;


    s.y = 0;

    s.h = 480;

    d.y = 0;

    d.h = 480;


    SDL_Init(SDL_INIT_VIDEO);

    display = SDL_SetVideoMode( 800, 480, 0, SDL_DOUBLEBUF );


    parallax[0] = SDL_LoadBMP( "scroll1.bmp" );

    parallax[1] = SDL_LoadBMP( "scroll2.bmp" );

    for( int p = 0; p < 2; p++ )

    {

        SDL_SetColorKey( parallax[p], SDL_SRCCOLORKEY, SDL_MapRGB(parallax[p]->format, 0, 0, 0) );

        parallaxX[p] = 0;

    }


    static char buffer[20] = {0};

    while( running )

    {

        int currentTime = SDL_GetTicks();


        while (SDL_PollEvent(&e))

        {

            switch (e.type)

            {

                case SDL_QUIT:

                    running = 0;

                    break;


                case SDL_KEYDOWN:

                    switch( e.key.keysym.sym )

                    {

                        case SDLK_ESCAPE:

                            running = 0;

                            break;

                        case SDLK_a:

                            for( int p = 0; p < 2; p++ )

                            {

                                SDL_SetAlpha( parallax[p], SDL_SRCALPHA, 128 );

                            }

                            break;

                    }

                    break;

            }

        }


        SDL_FillRect( display, 0, SDL_MapRGB( display->format, 0, 0, 0 ) );


        for( int p = 0; p < 2; p++ )

        {

            s.x = parallaxX[p];

            s.w = parallax[p]->w - s.x;

            d.x = 0;

            d.w = s.w;

            SDL_BlitSurface( parallax[p], &s, display, &d );


            d.x = s.w;

            d.w = parallaxX[p];

            s.x = 0;

            s.w = d.w;

            SDL_BlitSurface( parallax[p], &s, display, &d );


            parallaxX[p] = (parallaxX[p] + 1 + p) % parallax[p]->w;

        }


        SDL_Flip( display );


        sprintf( buffer, "%d FPS", 1000 / (SDL_GetTicks() - currentTime) );

        SDL_WM_SetCaption( buffer,0 );


    }

    SDL_Quit();

    return 0;

}
 
Last edited by a moderator:
Dunno. My code on my pc is running at over 750FPS - and down to 45FPS on Pandora.


Anyway, here's video of both apps - (my main camera needs charging so I use my phone - unfortunately you can;t see FPS on either :( )

https://www.youtube.com/embed/2dbnz7QDPqE?feature=oembed
my demo


http://youtu.be/WM_z-A6dLqw


pmprog's demo - YouTube is editing vid at the moment to smooth it out. Alpha blend mode is missing on vid at present, but should be available soon.
 
Last edited by a moderator:
Dunno. My code on my pc is running at over 750FPS - and down to 45FPS on Pandora.
Fook, my SDL app runs at 166-144FPS on my work PC (140-120FPS in alpha).


Maybe I shouldn't code the game engine, because I'm obviously not doing something right


Edit: Hmmm, I think mine might be slower because I'm blitting two 800x480 images. If I cut them down in size, the FPS rockets up
 
Last edited by a moderator:
I can commit to delivering a game design document, describing in details what the game would be like in terms of mecanisms/display/interface and so on.


Of course, get inputs from the team members after I have a first draft.


But if someone else feel like they want to take a lead on this, I have no issue with that.
I very much like good horizontal and vertical shmups, and it looks like this project will be running along well... I'm quite busy at the time, but I'd at least like to help with finding out what the game should be like and how it can be polished, if you don't mind. Maybe I can also help organize things, but I may not be available at all times.
 
The GLBasic demo (first video) is quite impressive - you can actually get a lot of performance out of it!


I assume adding more sprites on screen would keep the frame rate relatively stable ?
 
As it's running over 30FPS and I've limited it, yes you should be able to get more out of it. Don't forget collision detection, scoreboard, AI and other bits and bobs will reduce this, but with careful management it could be a steady 30FPS (if we remove one layer of parallax and remove the large rotating sprites the FPS could be much better.
 
iPrice, could you give this version a quick test, and let me know the new FPS pls? Ta

ParallaxCheck.zip
 

Attachments

  • ParallaxCheck.zip
    6 KB · Views: 169
That gives a better result (around 45FPS), but the blue background "jumps up" about 8 pixels just as each blue blob moves off the screen.


Alpha blending gives 40FPS.


Just noticed the green ones do too. Plus this test doesn't cover the whole screen - just a third of it. Is this right?
 
Yes, that's fine. I'll have more of a play when I get home, I just wanted to confirm that my speed problem was really because of the image sizes, which it is.


Thanks
 
Im guessing no one has stepped foward and claimed to be the game designer cos it probably is a big commitment with lots of work with all kind of things, or did some one do it and I just missed it? You cant prototype air, there needs to be something there to try to achieve. Will someone be brave and commit to game design?

I can commit to delivering a game design document, describing in details what the game would be like in terms of mecanisms/display/interface and so on.


Of course, get inputs from the team members after I have a first draft.


But if someone else feel like they want to take a lead on this, I have no issue with that.
I have some ideas about how the game might look visually and in terms of story and atmosphere.I was thinking of a haunting vibe to the game.Crypts,Ancient crumbling cities mixed with technology,Some space levels,A final level set on the ancient homeworld of the aliens etc.Music could be haunting in places and melodic also.Music and graphics could echo each other to a degree.Also what do you think of the warp-ram idea I suggested earlier in the thread?The ship would boost forward , strike enemies and return to its point of departure.It could be powered up by holding down a button or such.Im willing to commit a story and work with you on game ideas etc.I can devote alot of time to this game as im very interested in working on it.
 
As far as I know, you don't gain anything on "discarding to render pixels" on the pandora.


I got a library that apart from rendering textures also can render fonts and sprites. It already handles tilemaps and scrolling of them in a quite efficient manner. Soon also animated tilesheets.


Aside from that, it also has an audio-system, system for stringtables. I think I can already do two layers non-blended at a solid 60 FPS, I'll give it a go now.
 
Last edited by a moderator:
I think I can already do two layers non-blended at a solid 60 FPS, I'll give it a go now.
GLES or SDL? libDarnit?


Is there much point in me playing more with my test code? or should we just go with your engine?


I do find it interesting that several blits of smaller images is quicker than a single blit of a large image; Surely a single image would be faster, as you'd only need to lock each surface once, do one lot of transfers!?
 
Surely a single image would be faster, as you'd only need to lock each surface once, do one lot of transfers!?

That's what my demo "3" did - blitted a part of a large image onto the screen. Worked fine on pc but not on the Pandora.


I've got lots of other methods to play around with but I'll wait for slaeshjag to post his example. No point in working on optimising/updating my code if his works better from the off.
 
Im guessing no one has stepped foward and claimed to be the game designer cos it probably is a big commitment with lots of work with all kind of things, or did some one do it and I just missed it? You cant prototype air, there needs to be something there to try to achieve. Will someone be brave and commit to game design?

I can commit to delivering a game design document, describing in details what the game would be like in terms of mecanisms/display/interface and so on.


Of course, get inputs from the team members after I have a first draft.


But if someone else feel like they want to take a lead on this, I have no issue with that.
I have some ideas about how the game might look visually and in terms of story and atmosphere.I was thinking of a haunting vibe to the game.Crypts,Ancient crumbling cities mixed with technology,Some space levels,A final level set on the ancient homeworld of the aliens etc.Music could be haunting in places and melodic also.Music and graphics could echo each other to a degree.Also what do you think of the warp-ram idea I suggested earlier in the thread?The ship would boost forward , strike enemies and return to its point of departure.It could be powered up by holding down a button or such.Im willing to commit a story and work with you on game ideas etc.I can devote alot of time to this game as im very interested in working on it.

Game design = game mechanics. Thats what we need at this stage. I recommend you take a look at how game design documents are written so that your ideas can be used in an efficient manner.
 
Back
Top