Posts: 3,279
Threads: 170
Joined: Nov 2003
I myself was thinking of a similar method for making shooting games...but I never really do get around to implementing a lot of the ideas I have coz things are always so damned busy
Hey rel, wanna write an article on it for the next QBOA?
I'd appreciate it a lot if you could
If not then that's OK too of course
I'd knock on wood, but my desk is particle board.
Posts: 3,288
Threads: 167
Joined: Nov 2001
What kind of article do you wan't? I'm all for writing articles these days just to show you guys I'm actually doing something. ;*)
I'm also writing some articles for QBCM. But let's see what I can do.
The things I write for QBCM are mostly GFX effects. Some stuff you see in Mono and Disco.
Hey!!! I could maybe write some game specific stuff article so that it's a lot different from the ones I'm contributing to QBCM. Like sprite movements, object handlers, etc. ;*)
Posts: 3,279
Threads: 170
Joined: Nov 2003
That would be great, man
I'd knock on wood, but my desk is particle board.
Posts: 773
Threads: 71
Joined: Mar 2002
Still, if some game features multiple screens or even just one, how do I save this collision layer in memory? Wouldn't it take to much memory? It obviusly has to be pasted on the screen all the time so constant changes on the layer(holes) have to be saved.
Posts: 3,279
Threads: 170
Joined: Nov 2003
Quote:Still, if some game features multiple screens or even just one, how do I save this collision layer in memory? Wouldn't it take to much memory? It obviusly has to be pasted on the screen all the time so constant changes on the layer(holes) have to be saved.
Not necessarily...you could always make your blitting routine in a way where it only draws what has been changed. it's a lot of work and most of the time is spent in logic, but the bottleneck is video so despite the added code, it will update much faster. And yeah of course it's going to take more memory, but we're not dealing with 640KB limits anymore
Take advantage of EMS or XMS if you have to. If your layers are simply bitmaps, it's neither difficult nor wasteful to directly alter them as they are blown apart
And you save the collision layer just like any other layer. if you can save one, you can save many. It's just a matter of properly using your resources
(I could have never done Fundee without XMS memory)
I'd knock on wood, but my desk is particle board.
Posts: 3,343
Threads: 83
Joined: Mar 2003
I'm a newb at all this, but if you got the maximum "height" of a level:
Code:
+-------------------------------+
| |
| highest pt |
| - |
| / \ |
+-------------------------------+
It wouldn't be nessecary to draw a hit layer etc if the thing you're checking is above this height? Maybe this would speed things up?
Posts: 773
Threads: 71
Joined: Mar 2002
Yeah, it's time for me to get my hads dirty with RelLib XMS routines.
I think I would even be able to pull of horizontal scrolling using RelXMSPut. Not sure...hmmm.
Posts: 6,419
Threads: 74
Joined: Mar 2002
No need for EMS for multilayered, parallax, 8-directions scroll (as long as it is made of tiles). If you want to know how to do this, give me a call. It is so damn simple that it hurts
Posts: 773
Threads: 71
Joined: Mar 2002
What do you mean "as long as it is made of tiles"? Of course that this collision layer cannot be tile based.
Posts: 6,419
Threads: 74
Joined: Mar 2002
Oh, sorry, I was not talking about this project in concrete, but about any project that would require tiled scrolling.
![[Image: anya2.jpg]](http://rel.betterwebber.com/Mypics/anya2.jpg)
