Homebrew competition!!


On a slightly unrelated note I put in a frames per second function for developing and when I run on my pandora it only runs at 20 frames per second :(


UPDATE


I solved the issue by changing the hex colours to anything but true black (why isn't true black showing up?) But when I ran the game on my Pandora my FPS function was giving me 20 FPS and it's pretty sluggish to play. I'm thinking of jacking PyGame in as it's soooo fooking slow on the Pandora I may as well learn SDL and C++ to get something worth playing! Sigh, learning curves eh
Given that you've put time into learning Python and PyGame, I'd stick with it. Without seeing your code, I doubt it's engine you picked (PyGame gets very competitive framerates), but the algorithms you're using. Try profiling your code to figure out where the slow spots are (google for "python profiling" and "python timeit"), and see if you can't figure out some way to do the heavy-lifting faster. Python has a lot of speedy built-in tricks that you just have to know to look for, things like "heap.sort" or using a dictionary as an always sorted list (so you never have to sort it yourself).
 
Bit annoyed. My game is practically finished (level, collision detect) I only need to add in pistol, shotgun and machine gun classes. Thinking of throwing grenades and a throwing axe in too.


Anyway I ran my .py file on my pandora the sprites don't show up :(


They're just not there...yet when I run on my ubuntu laptop they show up fine????


:( :( :( :(: :( :)(


Laptop python version



Code:
[code]snow@snow:~$ python

Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 

[GCC 4.4.5] on linux2

Type "help", "copyright", "credits" or "license" for more information

Code:
python 2.6.2 

GCC 4.3.3



On a slightly unrelated note I put in a frames per second function for developing and when I run on my pandora it only runs at 20 frames per second :(


UPDATE


I solved the issue by changing the hex colours to anything but true black (why isn't true black showing up?) But when I ran the game on my Pandora my FPS function was giving me 20 FPS and it's pretty sluggish to play. I'm thinking of jacking PyGame in as it's soooo fooking slow on the Pandora I may as well learn SDL and C++ to get something worth playing! Sigh, learning curves eh


Looking at your system specs on the Ubuntu machine I would suggest trying to compile the newer version of python, on your Pandora, and add it to your pnd file. Were GCC is further optimized every release, I have always found that scripting languages (like python) improve dramatically with each iteration. Your hex color problem was probably a bug in version 2.6.2 but fixed by 2.6.6 maybe their was an increase in calculations as well. Oh, and look at your version of pygame as well.







Pandora python version
 
Pygame version is latest at 1.9.1


I'm using string to img converters so its not even rendering any pictures. I did that in the hopes of getting the best speed. I may post code up here later as seems the game won't be fit for the comp :(


Edit **


Damn my pretty much learning python and pygame from scratch this month and ending up with a game that works on my pc but lags on my pandora :(
 
Last edited by a moderator:
Is you tiling method efficient? Maybe try using larger tiles? I wouldn't give up this soon, man, we're all here to help.
 
Never draw each single tile every frame. Create a buffer of, lets say, 1200x480 (if you only use side-scrolling) and only redraw it when the the shown screen of the pandora hits its borders, otherwise just blit it in one.
 
No I think I'm going to give up on Pygame but try and do a transfer to SDL which seems to run a million times quicker on the pandora. If you play BubbMan2 (also a pygame) it's pretty dog slow on the pandora too so I think it's just a pygame issue.


My game was very minamalist and I enjoyed learning Python and Pygame but it's a shame it's so slow. By the time you get to level 3 (which is a big level) my FPS function is returning 4 frames per second. Damn my idiocy for not testing on my pandora sooner (admittedly I was digesting a python/pygame book a night).


To be honest my game was pretty fugly and it was a good learning curve but it now means I have to start from scratch learning C++ and SDL! lost 21 days of competition time dammit!!


Oh well, gives me an excuse to learn C++ and SDL and I may even learn how to put slopes in my next game. B)
 
Thankfully sdl is extremely simple, needing only initialisation, blitting, flipping/updating and probably colorkeying for basic graphics. Also once you've loaded an image you can treat them all the same, so there's little special treatment for a bmp vs png etc
 
Never draw each single tile every frame. Create a buffer of, lets say, 1200x480 (if you only use side-scrolling) and only redraw it when the the shown screen of the pandora hits its borders, otherwise just blit it in one.

I don't see what the big advantage of this would be.


Sure with multiple layers you would end up drawing only 800x480 pixels instead of 800x480x(number of layers) pixels each frame (assuming you are moving inside the cached area and use a tile on every position so you don't have empty space).


But then you would have to recreate the cache every now and then when the player actually leaves the cached area.


Assuming the Pandora is not fast enough to render your layers every frame, it surely won't be fast enough to recreate the cache in the time of one frame, so the player would experience a lag every time he leaves the cached area.


In my eyes this only either works with small levels (like most levels in SuperMeatBoy which are one screen in size) or in games where you have a transition between several small areas anyway, so you could mask the caching process with some sort of fade effect.


Games like Super Mario, Sonic or MegaMan would not be able to work this way if I understand it correctly (maybe I am missing something), because you move way to fast and don't stay in one place for a long time resulting in many cache redraws (you also can't make the cache too big or else you hit the Pandora's memory limit).


Anyway, my tests have shown that the Pandora is fast enough to draw 3 layers of 48px tiles (=17 tiles horizontally, 10 vertically) at 30fps (using C++ and SDL and few alpha blending, which already slows things down) - using a not very optimized drawing function.


PyGame might be a bit slower, but you simply could reduce the number of layers or don't "overfill" your maps, so you end up with many "empty" tiles, which don't need to be drawn anyway.


foxblock out
 
I don't see what the big advantage of this would be.

Mmh? I've had a game drawing 8x - tiles, one layer. The pandora doesn't handle very good if you draw every tile every frame. With caching it works far(far) better. Maybe it doesn't matter at 48x but at smaller shapes it seems to.

Games like Super Mario, Sonic or MegaMan would not be able to work this way if I understand it correctly (maybe I am missing something), because you move way to fast and don't stay in one place for a long time resulting in many cache redraws (you also can't make the cache too big or else you hit the Pandora's memory limit).

I've a game that had 5(3 lesser filled, completly filled backlayer, medium filled mainlayer) layers of 16x - tiles running fine on the WiZ with 80-90 FPS whilst scrolling like you would expect it in Mario/Megaman. Somewhat compareable to 3 x 48x layers on the pandora, I think.


The "caching" doesn't take 1.5x longer time than it would for rendering one frame. But it only has to be done every few seconds.


Please do the test: Check how long it takes to blit 1000 800x480(EDIT: 1200x480) pictures on a 800x480 screen. And then how long it takes to blit 166k 48x48 or 1.5Mio 16x16. Maybe I'm completly wrong....


EDIT:


Did some dirty testing: Infact blitting caches is much faster than blitting 8x8 tiles and still faster than 16x16 tiles. But then a little slower than blitting it in 48x48 tiles... Ask me why, I've no clue of such things.... But setting videomemory - lines with memset() is also faster than setting it's single pixels with a normal assignment...
 
Last edited by a moderator:
^ The game dynamics (movement, jumping) look spiffy and hectic. I can imagine some fiendishly hard levels in that game's future :p


By wastebin I assume you're starting on the SDL version you mentioned earlier?
 
This was level 3, I had designed it to make you go absolutely mad. I'm yet to complete it myself so I can't show videos of 4 and 5.


4 is about twice the size of 3 and 5 is mahooosive. I was going to bring in bullet functions and things but alas learning C++ will be jarring :(


All sprites are rendered from text and sound is also rendered as binary, I didn't think it was too shabby for a 54kb py file :)


Shame stupid Pygame is a big fat load of crap on the Pandora :(


http://www.youtube.com/watch?v=d0V4aPSj8L4


And well, I may as well give the source code. If someone learns something from it great :)


Also is that effective tile rendering?


Copy the code and save as a .py file then just double click on it on your pandora. I'm pretty sure level 3 will be at about 4 FPS on the Pandora but should work ok on pc


***realised my source crashes on full screen, ill sort that out and upload again.
 
Last edited by a moderator:
Is you tiling method efficient? Maybe try using larger tiles? I wouldn't give up this soon, man, we're all here to help.


All sprites are rendered from text and sound is also rendered as binary, I didn't think it was too shabby for a 54kb py file :)


Shame stupid Pygame is a big fat load of crap on the Pandora :(


And well, I may as well give the source code. If someone learns something from it great :)


Also is that effective tile rendering?


Copy the code and save as a .py file then just double click on it on your pandora. I'm pretty sure level 3 will be at about 4 FPS on the Pandora but should work ok on pc


***realised my source crashes on full screen, ill sort that out and upload again.

Don't give up buddy! I like the look of it and I actually want to play it. I'm sure there are members here willing to help you figure it out. You'll lose a lot of time trying to learn C++; I'm not a great programmer, but I would think that PyGame is still the way to go due to my limited exposure with C++. I don't think you'd really need the power of C++ here when PyGame should be fine.


Then again, I don't really know what I'm talking about.
 
Last edited by a moderator:
Spikes, oh spikes... is there any place in a level they won't fit :p

screenshot.png
 
Last edited by a moderator:
Spikes, oh spikes... is there any place in a level they won't fit :p

On a related note, my game actually will have spikes and pushable boxes, just to fit into the cliché of the generic indy game, oh noes! (though I am not too sure about the spikes right now)
 
No one likes my game? :(
Richiz,


You're further along than I am, and it reminds me of some very cool Commadore 64 games. Jump Man comes to mind. I wouldn't trash the code. Seeing if you can get somebody to help you with the bottlenecks, or profiling it to see if you can find them yourself seems the better way to go.
 
Last edited by a moderator:
Put the source up and maybe we can suggest some optimizations :)
I think I won't put the source up...not yet anyway as I was hoping to get a whole new game going as I did that one in 23 days. I'm finding C++ a lot more difficult and cumbersome compared to Python though so by the time I've learnt how to use I'll probs only be able to port the above existing game!!


Will release source code on the 31st March when I submit my game though :)
 
Richiz, were I you, I'd just keep going in Python, and maybe drop $25 on the eBook copy of Beginning Game Development with Python and Pygame. It's an awesome book, and with lots of luck, it'll help me get a very simple 3D game up before the deadline.


I'm really looking forward to seeing your code released when the competition is done, though! Your game looks like a lot more fun than mine is... Also, make sure you don't try to optimize things too soon in the development process. Optimize only when things are finished, otherwise you'll just make things more difficult for yourself later.
 
Last edited by a moderator:
Back
Top