Heaven/TQA

yup. i know this from jet boot jack... but again...any commercial finished game around except joust? i mean virtually more than 4 sprites per scanline...

of course all comes down to the game design... will you do a horizontal shooter? a platformer? racing game? well... it's up to you... and then you have to design all around the hardware/software abilities. my attempt in the sprite multiplexor came just in mind simply because i have never seen atari games using it! except joust... i don't mean sprite splitter via DLI like river raid or bounty bob strikes back etc... or mirax force... i mean a "real one"... and on other platforms this technique was common used but not on atari... i don't know why... of course my one is a generic approach but think of it addapting and modifiing it to your personal game... then you can simply avoid restrictions which the engine might not handle good enough.

You can't really convert them. You can create a ATR with a small bootloader to run your binary file though. MAKEATR is one such utility for the PC. You could probably also just use DOS and rename the file to AUTORUN.SYS. There are other game DOSes out there too. PicoDOS is one that I remember. Are you doing this to load them in an emulator or on the real thing? Most emulators let you just run a binary file without making it into an ATR. On the real thing, you could use APE's PC-MIRROR loader to run the file. 836555[/snapback] you can use our PC tool "XBOOT" which generates an ATR image with the exe file and a small boot loader for the file. see xasm.atari.org

that's exactly how i want to have 8bit hardware... simple plug n play solutions... so i could put all my game files on the harddisc? any specific regarding harddisc? and this would be a nice quick test setup... hmmm...i have some harddiscs lying around here... and some CF cards... but i can't do anything with my ATRs? right?

and of course not just a simple "linear" colour table but why not an exponential or logarithm one? but i am not a gfx guy...i am not sure if this is handy.

just played around little bit... emkay... this raster feature just works with the internal colour numbers of atari... what you want is to exclude the colour numbers 0-15 so your palette would be f.e. 16-240-16 or similar to that... am i right? what i would like to have in this feature is a simple but nice dither effect like in many amiga/atari ST games esp. the ones with raster effects backgrounds (turrican or enchanted land f.e.) have a look on dely's lewis_atari g2f picture and have a look on the background then you know what i mean...

but is this effect not simply baused by the atari palette? as grey are colours 0-15 16-31 or 240-255 are more brown colours?

1st figure out which characters are used for the fruit. then have a look where the character set is stored (charbase). now you get the data with charbase+character*8=adress of data then change the bits there... 1st 8 bytes are the left part, next 8 bytes are probably the right part... to "see" the font you can f.e. atari800win emulator save the charset into a file and then load it into any font editor...

cool thing but what are the improvements?`

i can offer assembler source codes: - abbuc intros - really unreal intro (portions...) ...

impressive... still open question... what will happen to the static background? will it remain static?

Emkay, can you please post a screenshot of g2f mockup screens just the antic 4 screen and just the pm data separate? it makes it more visible how the pm data is handled in your example. thanks.

for bubble bobble you would definitly go for software sprites i am afraid, tezz. as my one is definitly for hardware sprites only.

yes. exactly. not sure how to handle this in a nice way.

new v6 version of my engine available. look @ the programming forum. source code included.

new version v6: - handles 16 virtual 8x8 sprites - each one has it's own adress field so can have unique shape - ring buffer (flickering) not implemented yet for more than 4 sprites per scanline - timing issues cause some garbage on screen due to non optimised code i hope you get my idea... plex6.zip

ok... 58% of wow patch downloaded... aarg... so here more joust revers engineering: at $a2d9 there is lda #$0b = 12 bytes per sprite to copy...if you change this value f.e. to 6 than you realise that one sprite is just copied half... but it its interesting... the joust engine seems to work similar to my engine as when flying around you see how this "half sprite" is flipped through the players on screen...

at $0f00 you have the sprite data for joust... just enter F 0f00 0fff aa and you see just line instead of the sprites...

try to play joust at expert level right from the beginning...soon you have more than 3 enemies per line and you see how the engine starts to flicker through the virtual sprites...you can press space to stop the action (but the gfx engine is still working...so it gonna flicker in pause mode as well...) entering the monitor by browsing through the dlist via DLIST command you gonna see the DLI bits... now lets have a look @ $0200 where the DLI routine is... and voila... there is the position code... ($a4ca) now play around with the DLI via build in assembler... it's interesting that when f.e. switching off players or whatever the joust engine is working internally with the sprites only...so the visible part is "just for the viewer"... f.e. you can see collisions even there is no sprite there (but you can notice it via the spikes which are missles) and when watching closer the DLI routine you gonna see that there is no DMA code for feeding GTIA the player data...

damned...forgot to mention that the hardware players are filled with no. 1-4 so you can see how the engine is projecting the virtual sprites on them... in general you would not notice that the engine is using different players but you just see the sprite moving around...

here is another debugg version (oh... have some coding time while i am waiting for download completion of the german world of warcraft patch...) just for the guys who are not familiar what i am doing... i am searching for a flexible player missle engine which would be possible to use the hardware sprites as clever as it can for displaying more sprites than possible... the white lines are the DLI zones where the engine is setting DLI bits... in this zones it then mappes the virtual players into the 4 available hardware sprites... it checks if there are conflicts in terms of overlapping and then should skip sprites who overlapp... a good reference for this method is the one link i have posted... this method (which sorting) is also used on gameboy (GB;GBA,SP) and amiga or C64... but i found a similar hardware with this 4 sprites per scanline restriction and this is the MSX-1... if you search the net or the atariage forums i have mentioned years ago the so called "ring buffer concept" konami is using in their gradius games f.e. on atari i can just recall one game which i am trying to analyse and understand now for more than 10 years (and basicly this is why i want to ocde an engine similar to this as well)... is joust... the joust are players and the spikes are missles... the background is antic e so are the eggs... and you see the "ring buffer flickering" when more than 4 players are in one scanline... this ring buffer method is still missing in my engine... plex5.zip

forget the last one... plex5.zip

ok... here is an old source code written dec 2003... it moves randomly players around... the flickering is because when there are more than 4 virtual sprites on a scanline. at the moment the mapper does not disable them... www.student.oulu.fi/~loorni/covert/rants/sprite.htm plex4_16.zip plex4_8.zip

i will post the source code of my sprite multiplexor based on c64 technique for hardware sprites and if it is still working my sprite routine for antic e based on my time pilot demos... (if WOW will let me do... )

hmmm... miker...but is this nice? just 3 colours per sprite and each of them has the same + background... i don't know... but i have to check the game if its done in antic e... i spend yesterday few hours to rethink my sprite multiplexor (esp. sorting routines) and i would like to setup a kind of "atari ST" demo like competition: who can display max amount of sprites... ok 1st we have to define what kind of sprites...player/missle, charmode or antic e and if highres which size???