Holly _ Platformer Adventure Demo

[stevmjon]

    

The demo looks good and feels nice and slick as always !  - Had a quick look-see at the code before, and  it seems like you've made some improvements.  But, there's certainly some room to move in that regard. but anyways.

thanks kev. i found that functions and types are very handy. it really shortens code, and makes it easier to edit.
i also optimised the rendering using the multi pass method, as well as dirty rectangles method. i also used 'copyrect' between the fx image (backscreen) and the video backscreen because too much of the fx image (backscreen) wasn't being drawn. it definately sped up render time though. do you think it is o.k.?

* while in game play, press F5 > 3 > H or J  (everything in boxes is fx image backscreen)

some of the code is a direct copy/paste of my old code. i actually don't use all of it, it is just there for reference. i will cut it out soon.
also, the mapper tab is not very well optimised, because i didn't expect to grow it so much. it was mean't to be small and quick. i just kept adding to it, and adding to it. it is actually a little hard to edit this section, but it is almost finished. it has been a learning experience though.

stevmjon

[kevin]

thanks kev. i found that functions and types are very handy. it really shortens code, and makes it easier to edit.

   They make code more modular / secure.  Which is one of those programming concepts that's easy to overlook.  While there's some functions appearing, there's certainly room to move in this area.   One thing that worries me about the new code is that it's still mostly open scope.  In other words, everything can see everything else.  While this might seem easier from a deign point of view,  it's a logic error waiting to happen.   So the more we more towards encapsulating our routines within Functions/Psubs the less likely those type errors will be. 

   That probably sounds critical , that's not my intent.  Which is simply that, prevention is the best type of cure.. 

i also optimised the rendering using the multi pass method, as well as dirty rectangles method. i also used 'copyrect' between the fx image (backscreen) and the video backscreen because too much of the fx image (backscreen) wasn't being drawn. it definately sped up render time though. do you think it is o.k.?

    Yep, but i've only briefly a looked at this the other day though, had some difficulties following it to be honest ;)  -  it certainly seems to be an improvement in terms of evening out the amount of the memory that's being moved each refresh by the CPU.   From what i understand, you're rendering the backdrop as video image directly to the screen, then rendering the scene fragments (that require blending) to the fx image, then copying those chunks down to the screen, so the output image is composite.  Which is indeed what we're after.   

     There's still some opportunity being missed here I feel.  As we can occlude backdrop elements by the foreground map layer.  So when a foreground chunk is completely solid, we don't render that portion to the FX image at all, we just draw it directly to the main screen.  So that way we're saving time by not drawing anything that's being drawn behind that chunk, and then not transferring this chunk from the FX to the screen.   The only portions we want to be shifting are those that we absoluetly have to, which are those that are knowingly not completely solid foreground and knowingly not nothing (sky/backdrop), so we must blit them.   

     I set up an example last night (using your map data) that uses the method above. The demo includes a few variations on the same theme as well as the standard 'brute force' method for comparison.    The results aren't mind blowing, but they're pretty pleasing none the less.  If I run the demo in 1280 by 1024 (32bit) and render as brute force (draw everything  to fx image, transfer fx image to screen), it takes this machine about 17->18 milliseconds to do that.    By masking the scene, that time reduces to about 12->13 milliseconds  for the same section of the scene.    obviously as you move through the world space the performance gain fluctuates depending upon what's in view.   It's not uncommon for it render inside the 10 milliseconds at the resolution, given that world data.   Obviously lowering the resolution further improves the result.   So it'll scale down for even older hardware better.

    I'll post the example later.    BTW,  Don't be too surprised to see your map/arts used during the upcoming mapping imporvements pass( next beta).  It's much more visually stimulating than looking at some coloured squares on the screen :)

 

* while in game play, press F5 > 3 > H or J  (everything in boxes is fx image backscreen)

   I liked the heads up display feature.   

some of the code is a direct copy/paste of my old code. i actually don't use all of it, it is just there for reference. i will cut it out soon.
also, the mapper tab is not very well optimised, because i didn't expect to grow it so much. it was mean't to be small and quick. i just kept adding to it, and adding to it. it is actually a little hard to edit this section, but it is almost finished. it has been a learning experience though.

    So the mapper is the level editor ? - What's the keys/controls as I couldn't get anything happening really.

[stevmjon]

Yep, but i've only briefly a looked at this the other day though, had some difficulties following it to be honest  

i calculate each level, finding images that need to be added to the fx screen. then calc a zone to draw images, and not draw others. thats why there are so many gosubs and functions. i want to draw the absolute minimum.

There's still some opportunity being missed here I feel.  As we can occlude backdrop elements by the foreground map layer.  So when a foreground chunk is completely solid, we don't render that portion to the FX image at all, we just draw it directly to the main screen.  So that way we're saving time by not drawing anything that's being drawn behind that chunk, and then not transferring this chunk from the FX to the screen.   The only portions we want to be shifting are those that we absoluetly have to, which are those that are knowingly not completely solid foreground and knowingly not nothing (sky/backdrop), so we must blit them.

i didn't think of drawing solid tiles directly to the video screen.
also, should i cut up the video backdrop to only draw the portions that will be visible after fx portion are copied over? i just draw the video backdrop whole (i thought big bits are faster than multiple smaller bits).

So the mapper is the level editor ? - What's the keys/controls as I couldn't get anything happening really.

> it is best used in 1280*900 screensize (press F7 in menu at start of game). focus on what's written in the right side of the screen.
tiles won't paste down if there isn't enough room for the whole set (approx 5 rows are pasted with each mouse click, if room).
> also, you must be able to see a preview image, enclosed in a purple box, that shows you which tile you are about to paste. if you can't see this, you haven't clicked any of the small white boxes on the right side of the screen. these boxes are your selections. sometimes two boxes need to be selected.
> to paste images (trees), you need to click on the ground surface.

also, i learnt about functions about half way through this code. if i started again, i would definately have more functions.

stevmjon

[kevin]

 Steve,

 

i calculate each level, finding images that need to be added to the fx screen. then calc a zone to draw images, and not draw others. thats why there are so many gosubs and functions. i want to draw the absolute minimum.

     Well, it makes good sense to eliminate as much redundant rendering as possible.  Got to be careful though as there's a point though where our routines to remove rendering, can actually cost more than the rendering itself.    For stuff like the sprites within the screen,  we want to avoid any overlapping areas.    The approach that i'd be taking is working out what tiles the sprites on screen cover (masked against the foreground).   With the occlusion approach above, we only have to draw regions where a section of the sprite is over a sky tile.  As those tiles won't be drawn during the map pass.  So we're slotting the missing parts into the scene.  

i didn't think of drawing solid tiles directly to the video screen.
also, should i cut up the video backdrop to only draw the portions that will be visible after fx portion are copied over? i just draw the video backdrop whole (i thought big bits are faster than multiple smaller bits).

    The way you're doing it is a more optimal solution, as the rendering will be in parallel.   What occurs, is the GPU is drawing the sky,  while the cpu it's doing the rendering of the block sections/chunks to the FX buffer.  

    In terms of the image blitter, the smaller the block size, the more it'll choke on it.     Which is really evident with 16*16 and 32*32 blocks say, but the larger the blocks, the less impact stalling has.   The 100 * 100 size you're using, aren't small enough to really choke it, but are large enough to benefit from the off loading onto the GPU.

    Here's the demo from that other day (got side tracked.. again ;) ) -  It uses a few variations on the foreground occlusion approach to try and remove redundant scene drawing.   The world is just the level data & gfx data dumped into a single file.  The example contains the loader/save function for this job, plus a bunch of functions for various tasks.  I've documented most of it, it's not really much to it..   The code was written in PlayBASIC V1.64M Beta11 or beta 12 (or above), as such it has a switch at the beginning to toggle what version you're running.  

     Performance wise I tested this on the Duron 800 mhz system the other day, and it runs between about 30fps to 60fps at 1024*768.   Which is well within the bounds of the being playable on that hardware. 

      Use the number keys to change draw modes (0 to 4) or the space bar to step through them..

     Steves Platformer With Map Occlusion Test

[stevmjon]

thanks for your demo kevin.  i am combing through it right now.

i am eager to work out the fastest rendering method.

  stevmjon

[659_minifly]

I really like this demo it is a very good and great job you have done. I can't say anything more/ felicitation.

[stevmjon]

thanks 659_minifly.

i am glad you like it. i am now adding in sprites & weapons. i will post when they are ready.

  stevmjon

[stevmjon]

hi

just letting you know that i have updated the game again.

http://www.users.on.net/~stevmjon/
*once on the website, scroll to bottom of page for new game link*

> added sprite collision
> added a weapon(mine) & character sprite(beetle) _ all animated

fire button = space bar / left mouse button

now the routines are in, it should be easy to add to.

 enjoy, stevmjon

[kevin]

Only played the new demo a tiny bit, but it's good to see the other characters appearing again. 

[Devain]

I couldn't get it to start. It tried to maximize the screen but never worked.

Tried to run it on my work computer, though, which is running at some insane resolution.

[stevmjon]

my next update has better screen selections. i have brought back the menu again, with more screen resolutions to choose from.

hopefully this will work for you.

stevmjon

[Devain]

Worked! Really like the style of it, but there's not that much gameplay beside the jumping right now. What are your plans for the future?

[stevmjon]

hey devain

my next update, comming very soon, is a bigger area, with some more baddies, and items to collect. the game play should grow faster now, as all i need to do is simply add more gameplay.

my goal is to have weapons, items to use, baddies to deal with, and puzzles to solve using your items and weapons. also as game play time increases, so does your abilities, items, weapons etc. i am also going to add foreground objects, moving at a different rate as background objects to help with giving the game a feel of depth.

i will post updates more often, probably each month, and any suggestions are welcome too.

stevmjon

[stevmjon]

finally made a slightly bigger demo.

> menu is back
> all characters & weapons are animated
> titlebar is updated and operational

note: pressing "v" during game play turns  on / off  screenvsync (smooth display).

http://www.users.on.net/~stevmjon/

also, my website is updated and only has the new demo.

   have fun, stevmjon

[micky4fun]

hi stevmjon

this is really coming along nicely , can see a great deal of work has gone into this , i know this as taken you ages to do , but it well looks worth the wait and effort you have put ino it ,
keep up the good work

mick :)