Brutman wrote:Well, we'll just have to try it out tonight on the real deal and see how it runs. Although if you are shooting for an 8Mhz AT with 16 bit video this might be painful.
My original target was a 7mhz Tandy 1K, but the hardware just isn't up to the job of realtime sprites without flicker.
Brutman wrote:Where is the bottleneck? Are you painting portions of the screen, xor'ing data, or what? (I have a little experience with fast screen updating ...)
The only time you can draw to the screen without the risk of flicker (and snow on real CGA cards) is during a retrace period. The horizontal retrace is so short that by the time you detect that you're in it, it's already ended, leaving the vertical retrace as the only real option. Most of the bottleneck is that PC video cards have no built-in sprite handling, so it's all software.
To draw a sprite without corrupting the background behind it you are stuck every time you draw it with restoring the original background, grabbing the background at the sprite's new location, then doing an AND mask to erase where you'll be drawing the sprite and then ORing the sprite's color data. You can't even take the XOR shortcut since this particular color mode is 4bpp packed in alternating stripes... (every other byte being a text mode character 0xDD). The pixel packing also means you need two copies of the sprite (since it takes to long to SHR 4 and carry on the fly across 6 bytes) in addition to the mask, and you have the overhead of figuring out which copy (even or odd aligned) you want to blit.
Net result? 30 byte write to restore background, 30 byte read for original background, 30 byte read/write AND, 30 byte read/write OR working out to 90 bytes read and 90 bytes written PER 5x5 sprite. With five (six if you count the bonus item) sprites that's 450 bytes in and 450 bytes out... and a 8mhz 8088 just cannot manage to do that inside the retrace period... in fact it generally only has enough time free to do about 18-28 bytes depending on the code overhead.
AND you have to erase all of them then draw all of them together in groups in the opposite order so that if they overlap their restored backgrounds don't screw it up.
A possible solution I'm investigating is breaking the screen into 'sections' and only drawing elements within those 'sections' a certain period of time after the retrace. For example when the retrace occurs you can draw the bottom half of the screen, then by the time that's done the retrace will be showing the bottom half letting you draw the top. The problem with this is what to do when sprites overlap across those boundaries -- I'm still not sure how I'm going to handle that. The overhead of dividing them up and checking their position for redraw could take so much time it impacts game performance.
It's a problem all text-mode applications on the CGA face thanks to the unbuffered memory.
A better fix would be do to paging, but because this is a glorified text mode with every two pixels taking up two bytes (high byte $DD, low byte broken into pixel colors) it ends up 16000 bytes -- and the CGA only has 16k of RAM. (though I may make a tandy/jr port that uses their native 160x200 mode that has a lot less of these problems)
Brutman wrote:And why on earth do you not have a PCjr yet?

Because I have a limited budget, limited space, and a working 1000 SX? Only way I'd have room for a Jr would be to move the Coco down to the garage again, and that's not happening in the dead of winter.

The only thing about Adobe web development products that can be considered professional grade tools are the people promoting their use.