13 replies to this topic

[GameEngine]

I do not know what drives me but I am pretty sure that I will write the very first game of mine for XL computer this year.
I realized that what I need at first is some game engine with a feature list like this:
- character based playfield (some action)which is as much as full screen as possible
- playfield rolls both ways, so if desired it can but does not have to be fed with additional data
- horizontal and vertical scroll which is not that hungry for resources
- 1 bit (ORed = fast, 1 common color extra should make sprites look good enough) software sprites to use as PMG underlays (thus width should match PMG so 8 color cycles), preferably 5 of these, will see

So far I have scroll and soft sprites working (well, kind of - see bellow):
 MANAGER.zip   1.28K   110 downloads

(use joy0 and cursor keys to initiate action, for both only 4 main direction allowed)

The problem is that current incarnation of my Engine is way to slow (thats why you see flickering and there is more when sprites are at the top) !
For the screen I move 128 bytes (width) and update 32 line (2 lines hidden) adresesses (lower byte) for horizontal and roll full 32 adresses for vertical scroll. I think the real problem lies with software sprites where, so far, I used horizonatal preshifted data for it and was trying to avoid to many loops which unfortunatelly is not enough.

I write hoping that you will keep your fingers crossed so I am succesfull in optimizing it to the point where playfield scrolls both ways and 5 software and 5+4 (reused) PMG sprites gets refreshed within one frame (I really hope it is possible) thus every other frame is spent for game logic and character based action.

PS
If I am succesfull I plan to share version of this engine available from Atari Basic to facilitate game prototyping. If not, well .... then I'll lower my expectations I think cutting on the number of sprites and ability to scroll vertically (the later option looks especially interesting as it would allow me to move some processing into the next frame. On the other hand it would be more suitable for sideways shooter then. Hm..).

GameEngine

[Heaven/TQA]

1st of all it's quite good for the 1st attempt!

if you post the source we might find one or another way to speed up things by clever organisation of your data... i am sure...

go searching for analmux' super mario engine here in the forums where he explained how he is using a (very clever) and fast screen layout for software sprites + scrolling which does not need too much overhead...

[Plastron]

Also take a look at Jetbootjacks site there is the source for menace


http://www.jetbootja...sdownloads.html

[Shawn Jefferson]

Heaven/TQA, on Mon Jan 16, 2006 11:00 AM, said:

1st of all it's quite good for the 1st attempt!

if you post the source we might find one or another way to speed up things by clever organisation of your data... i am sure...

go searching for analmux' super mario engine here in the forums where he explained how he is using a (very clever) and fast screen layout for software sprites + scrolling which does not need too much overhead...

Also check out Gauntman's demo posted here somewhere that illustrates the scrolling. I finally understood how the MWP scrolling actually works by looking at his source code. Unfortunately, I will probably forget the details once I actually get around to programming a game.

[GameEngine]

Thanks guys for the hints and offer to help which I really appreciate (my lack of experience means I might go terribly wrong with some of my assumptions).
Actually I read this forum for some time and I saw both techniques you mentioned but these do not seem to fit my needs exactly.
I tried to design the scrolling engine so it capable of virtual screen (like Tiger Attack) so some interaction with off screen objects is easier. Also I plan to go for 25 frames/s so I think I need my own software sprite engine.
Basically want to have things well balanced not willing to trade neither framerate nor color (thus the usage of overlays) just to show plenty of fully independent sprites.

Now report on progress:
I did some optimizations to the code and instead of not fitting at all within one frame I have now around 8000 free cycles per frame. I base my judgment on the vertical position at which the last sprite stops to flicker, it seems there is ~10 rows at which CPU is no longer busy with sprites, now 10 rows * 8 lines * ~100 cycles/line = 8000? cycles/frame.
If the above true (I believe it is) it means that I have enough time left to maintain P/MG as I planned 5(plain) + 4 (reused).
Eventually I plan to go for 25 frames/s and double-buffered PMG so I will have all my sprites and no flicker.
 MANAGER2.ZIP   1.4K   79 downloads
Please do share with me your comments and remarks.

GameEngine

[GameEngine]

 manager.ZIP   2.17K   86 downloads
Still work in progress. PAL only Should be 25 frames a second.
Both ways wrap-scroll in character mode plus five double-buffered software sprites plus five plain PMG sprites. Use stick to move players. Software sprites interact with inverse characters - in case you want to know which are which.

Regards,
GameEngine.

[Heaven/TQA]

still find it pretty amazing!

[emkay]

GameEngine, on Sun Mar 5, 2006 4:10 PM, said:

attachment
Still work in progress. PAL only   Should be 25 frames a second.
Both ways wrap-scroll in character mode plus five double-buffered software sprites plus five plain PMG sprites. Use stick to move players. Software sprites interact with inverse characters - in case you want to know which are which.

Regards,
GameEngine.

That's what I say everytime. Building hardware extensions makes the machine no longer the original.
(exeptions are a 2nd pokey and ram/rom extensions because they were intentional by ATARI)
Clever coding makes better software and helps to push the limits of the original machine.

OK. Sometimes one has to stick around with the limits, so if it works on a pal machine only, it is better to have this restriction, than to have nothing.


Very good work here.

Edited by emkay, Sun Mar 5, 2006 10:55 AM.

[Stephen]

How can I test this? I tried loading it via MyDOS 4.53, but the machine just restarts.

Stephen Anderson

[Fröhn]

emkay, on Sun Mar 5, 2006 6:54 PM, said:

That's what I say everytime. Building hardware extensions makes the machine no longer the original.
(exeptions are a 2nd pokey and ram/rom extensions because they were intentional by ATARI)
Clever coding makes better software and helps to push the limits of the original machine.

Nah, 2nd POKEY and RAM expansion is also a no-go to me. Software should run on the original hardware which is a plain 800XL or maybe 130XE. I hate it that I can only watch 99% of todays demos on emulator and not my real 800XL. And no, not "everyone has a RAM expansion anyway". Look on eB*y and see what people have: 99% plain 800XL.

[emkay]

Fröhn, on Sun Mar 12, 2006 12:34 PM, said:

emkay, on Sun Mar 5, 2006 6:54 PM, said:

That's what I say everytime. Building hardware extensions makes the machine no longer the original.
(exeptions are a 2nd pokey and ram/rom extensions because they were intentional by ATARI)
Clever coding makes better software and helps to push the limits of the original machine.

Nah, 2nd POKEY and RAM expansion is also a no-go to me. Software should run on the original hardware which is a plain 800XL or maybe 130XE. I hate it that I can only watch 99% of todays demos on emulator and not my real 800XL. And no, not "everyone has a RAM expansion anyway". Look on eB*y and see what people have: 99% plain 800XL.

Well... it's kinda different.
The original machine is still kept, when someone is plugging a cartridge in which inhabits its own rom/ram and a pokey chip. It was intentional by ATARI.

Doing heavy changes, as the announced "new" graphics chip or dual GTIA or 16 bit CPU, makes the computer not being the same anymore.

[Fröhn]

emkay, on Sun Mar 12, 2006 2:39 PM, said:

Well... it's kinda different.
The original machine is still kept, when someone is plugging a cartridge in which inhabits its own rom/ram and a pokey chip. It was intentional by ATARI.

It was also intentional that you can plug an extra 512 KB in the back of a C64, or you could plug the Sound Expander cartridge with an YM3526 onboard to gain a total of 12 sound channels. But it is not a standard for making software, you can still download any game or demo and run it on the C64 you have stored in the attic. In my eyes the already small Atari scene makes itself even smaller by this hardware addon mania. The average 800XL owner will never see your 320KB demos on a real machine.

Quote

Doing heavy changes, as the announced "new" graphics chip or dual GTIA or 16 bit CPU, makes the computer not being the same anymore.

Yes, I absolutely agree with that. It is a nice toy to play around, but basically it becomes a new machine then.

[emkay]

Fröhn, on Sun Mar 12, 2006 2:14 PM, said:

In my eyes the already small Atari scene makes itself even smaller by this hardware addon mania. The average 800XL owner will never see your 320KB demos on a real machine.

Not only in your eyes. It's reality. When looking sometimes at Atariarea you recognize that.
Starting with double POKEY, using COVOX.... use "new" chips to enhance functions...

The polish scene always is cutting off from the "real" A8 ... turning the real thing into emulation and using different Hardware, giving the machine "advatages" that never are real.
To explain what I mean: Some software, that runs on the emulation, cannot be run on the real thing, right now.

[Fröhn]

emkay, on Sun Mar 12, 2006 6:40 PM, said:

Not only in your eyes. It's reality. When looking sometimes at Atariarea you recognize that.
Starting with double POKEY, using COVOX.... use "new" chips to enhance functions...

I've noticed this on other "small demoscenes" aswell, take the Commodore +4 scene for example: They also used home built 256 KB memory expansions and SID cards to enhance their machine. Luckily the scene turned away from the 256 KB expansions some time ago, so you can watch the demos now on a plain +4 (although without sound if you don't have a SID card).

Quote

The polish scene always is cutting off from the "real" A8 ... turning the real thing into emulation and using different Hardware, giving the machine "advatages" that never are real.
To explain what I mean: Some software, that runs on the emulation, cannot be run on the real thing, right now.

Luckily nobody will ever find out since nobody can potentially watch it on a real machine