>Yeah, pixel doubling happens at color change time, and I was thinking PC
>pixels in my counting not 2600 pixels :) But this way of doing it only
>happens when doing background and playfield only and we know there's no
>objects in the way. If there are players or other objects to do, things
>happen more or less the way you might expect. So for background and
>playfield you wouldn't even need the SHR, but in the other cases, you'd
>probably write a byte instead of a word? You tell me!
Looking at the code, this seems more complex than I was expecting :) In
the rendering engine, you use gs:di as the segment:offset for video memory,
right? I'm hoping to leave most of the object-handling code alone and only
change anything that says mov gs:[di]. In mode X, though, you can't do
word or dword stores to video memory - supposedly, the bank select register
can only handle one input byte at a time, so you can only mov gs:[di],byte.
>I was thinking 360 because most people are used to looking at games at 320
>by 200. If you go to 320 by 240 they might look squished. At 360 by 240
>you could squish them in both directions to get close to the aspect ratio
>people are used to seeing.
Hmm, true. 360x240 (or x480 with interlacing) isn't quite the same aspect
ratio as 320x200, but it's closer than 320x240 would be.
>Yeah, z26 runs at VGA speed now, wrong play speed, but check out Yars'
>Revenge then look at it on PCAE running at 60 fps. Our synchronization is
>still not perfect under Win95, I think maybe we need to use vertical non
>display interval instead of the retrace pulse, or maybe even page flipping
>:) but you get the idea.
Page flipping might actually be possible... if we get the rendering portion
into mode X, it's a small step to make the starting offset for the renderer
alternate between 0 and 32k on alternate frames. There wouldn't be enough
video memory to page-flip in a 480-line interlaced mode (320x480x2 > 256k),
but then you probably wouldn't want to anyway.
>I'm using Turbo Assembler 1.02 and Turbo C version 2.0. Assembly code
>SHOULD be MASM compatible though. I've tried it before and it worked but
>not lately :) If finding something compatible enough to develop with turns
>out to be a problem, let me know. I may have a copy of MASM I'm not using,
>and I may have a copy of Microsoft C I'm not using :)
Ok... I've got TASM 3.something and Turbo C 3.0, so I should be able to
compile your source.
>>I haven't done x86 assembly for a while.. looking at this, it feels like a
>>high-level language compared to 6502 assembly, though :) Damn, the 2600
>>would be easier if we could do stuff like CALL [TIAREGVECTOR + EBX*2] :)
>
>I had a hard time with it when I was first learning it. I was used to
>something much simpler too (D.G. Nova) :)
Well, was the other way round with me.. I started with 8086 assembler, then
kept getting frustrated at the 6502 when I'd have to use four or five
instructions to do what took the 8086 one, and there isn't even a multiply!
:)
--
Stella list is Administered by krishna@xxxxxxxxxxxx <Glenn Saunders>
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
+-shameless plugs-------------------------------------------------------+
| Stella documentary at http://www.primenet.com/~krishna |
| Nick's VCS links via http://www.primenet.com/~nickb/atariprg.htm |
| Write the best game, win framed autographs of famous Atari alumni!! |
+-----------------------------------------------------------------------+
