[atari7800] Re: Yet Another Kick In The Head!

Though there's only 19 scanlines of official vblank, there's also 51 scanlines 
that are not reliably visible on the screen.  It's up to you how many scanlines 
you want to draw, but if you stick with the official 192 lines, then you've got 
70 scanlines that are either empty or vblank.  You could use a DLI at the end 
of the visible screen and just consider that the beginning of vblank.

If that still isn't enough, you could try inserting DLI's after every several 
zones, and use them as triggers to update some display lists as soon as their 
zones have been drawn.  That way you're taking some advantage of leftover CPU 
time during the visible screen.  But if you try that you have to make sure that 
every DLI finishes execution before the next one hits, otherwise be prepared 
for an unexpected jump back to the start of your DLI function.

Redrawing the displaylists on every frame would generally be a bad way to go, 
but if everything on the screen is always moving then it might not make much 
difference.  If you do keep rebuilding the display lists, then you might as 
well pack them tight instead of allocating 20 sprites per zone even when 
they're not needed.  Right now you're getting the worst of both worlds - wasted 
memory and slower rendering.

If you decide to stop rebuilding displaylists on each frame, and instead only 
update the objects that have moved, then you'll get more performance but it 
will waste some memory.  I know you said you aren't really working on galaga, 
but at least for this demo 20 sprites per zone seems excessive.  The exact 
number depends on what you're working on, but I'd try setting the sprite limit 
to something that will almost never be exceeded, and write a flicker routine to 
handle rare exceptions.

The demo looks nice.  I wish Atari's version had those graphics.



----- Original Message -----
From: Christopher Tumber <christophertumber@xxxxxxxxxx>
To: atari7800@xxxxxxxxxxxxx
Subject: [atari7800] Yet Another Kick In The Head!
Date: Fri, 12 Nov 2004 15:41:08 -0500

> 
> Only 19 scanlines of VBLANK? Only 2166 cycles for game calcs per frame? Who 
> the hell thought that was acceptable? That's less than half the 2600 for 
> crying out loud!! Why does MARIA need to halt the 6502? Why doesn't MARIA 
> just run in the background, like, oh, EVERY OTHER SYSTEM AFTER THE 2600!!!
> 
> Whoa, I feel like I have a good solid grasp of this beast (on alternate days 
> "this hunk of $%^&$%") and then BANG, I keep running into this unbelievably 
> insane brick walls. Next time anyone whines about how crazy the 2600 is to 
> code for they're getting slapped 'cuz this console is absolutely 
> bizzzzzarrrrrre.
> 
> Anyway, attached is a demo of sprite handling routines I'm working on. This 
> demo displays 41 sprites. It's currently limited to 20 sprites per zone for a 
> maximum of 480 sprites on screen (though RAM would be difficult as each 
> sprite is 5 byes (X,Y,BitmapPointer,Width/Palette) and there's already a huge 
> chunk of RAM dedicated to the DLs). It does some movement but it's very 
> regimented because there's no checking for >20 sprites on a line and it tends 
> to crash due to memory overwrites if 20 is exceeded.
> 
> It also flickers like crazy because my routines are too slow to complete 
> every frame (I'm rebuilding the Display Lists from scratch each frame which 
> may no be the best way to handle things) since there only 2166 cycles 
> available (!!!!!). 
> 
> Horizontal movement is limited to 2 pixels which means things have to move 
> somewhat quickly or it looks jerky. Not really any way around it as I'm using 
> 320C mode and it's strange (of course!!) palette limitations means it's not 
> really possible to have two sets of sprites, with the second set shifted one 
> pixel in order to fake for single pixel movement. I really like the idea of 
> alternating between 320B and 320C every scanline in order to pull more 
> colours but it seems like something that could be really effective in a deme 
> but dificult to use in a game (maybe for something non interactive like a 
> scrolling border or something). Also difficult to design sprites for.
> 
> 320C gives 8 colours, though of course it's a little funky (each byte (2 
> pixels) can only access half the palette). I think 8 colours is enough to do 
> most classics (to '83 or so, anyway) though maybe with a little comprosmise, 
> especially if you modify the palettes mid-screen with interrupts. I'm 
> probably not going to be doing any ports, I just needed some sprites to work 
> with but I hope if you compare my demo to Atari's original 7800 port you'll 
> see where I'm going with this...
> 
> Chris....
<< galaga.a78 >>

-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

Other related posts: