[Coco] Development environment

Tue Mar 17 01:19:18 EDT 2015

Hi Hugo,

Thanks for the explanation of your 16-color sprite tricks.  Did you read about
this somewhere or did you come up with it all on your own?  It does impose
some constraints, but I think it's very clever.  This would be useful for the
coco.

I played around with your game Ikham a little bit.  It runs just fine in
DosBox on my linux PC.  Where did you get all of the graphics and textures for
things like walls?

Just for fun, I have attached a copy of an old DOS program that I wrote over a
weekend when I was in college.  It's an alarm clock using the 16-color 640x480
VGA graphics mode with greyscale.  It has antialiasing for the rotating
numbers, and another cool looking display mode where the digits morph from one
to the next.

I have published the source code for DynoSprite. It's at:

http://github.com/richard42/dynosprite

Richard

On 03/15/2015 01:56 PM, Hugo Dufort wrote:
> Hi Richard,
> I'm a bit late answering to your message, but here's the current state of my
> projects. I have lost some of my projects back in the time I was programming
> in Turbo Pascal. Sadly the diskettes were damaged when I moved from my
> university room to my first apartment. I don't have my code from the EGA
> 16-colors era, just my personal notes. But I'm progressing in ASM 6809 and I
> should be able to post a few screenshots and/or short videos soon. I was using
> a rather complex palette definition trick back then. In fact, I had a few
> strategies for fast 16-color rendering of transparent sprites; I used them in
> different situations. Here is a sketch of one of these strategies.
> 
> I want to render sprites using the tightiest loop possible, e.g. something like:
>     Load byte A from screen
>     Load byte B from sprite
>     Write A OR B (bitwise OR operator)
> 
> We can apply the whole sprite byte to the background byte without any further
> operations. If we want to use even/odd horizontal positioning, we can define a
> slightly different sprite for odd positions.
> 
> To achieve this, I need to define the foreground (sprite) colors as a mask
> that always overwrite the background colors. We will have a limited number of
> colors for the sprite and for the background, but that's okay. Here are the
> color masks for the sprite, as well as the constraints:
> SColor12: 1100
> SColor13: 1101 (a lighter/darker version of SColor12; see why below)
> Scolor14: 1110
> Scolor15: 1111
> Scolor00: 0000 (transparency)
> Scolor01: 0001 (used to give the illusion of semi-transparency or "glass"; see
> the explanation below)
> 
> For the background, we define colors that will always be masked by sprite
> colors (except Scolor00):
> BColor00: 0000
> Bcolor04: 0100
> Bcolor08: 1000
> Bcolor12: 1100 (will render the same as Scolor12)
> 
> Next, for fun, we can define colors that are derived from SColor01, e.g. these
> colors will combine with the background to give "semi-transparency". For
> example, SColor01 OR BColor12 gives Tcolor.
> Tcolor01: 0001 (a lighter/darker version of Bcolor00)
> Tcolor05: 0101 (a lighter/darker version of Bcolor04)
> Tcolor09: 1001 (a lighter/darker version of Bcolor08)
> Tcolor13: 1101 (a lighter/darker version of Bcolor12/Scolor12; this mask gives
> the same color as Scolor13)
> 
> We can also define a "super-background" color which will always render
> consistently through any sprite color:
> Bcolor15: 1111 (similar to Scolor15)
> 
> Finally, all the other available colors are free to use but not as background
> (e.g. platforms, interface, walls, solid objects, etc.)
> Ecolor01: 0010    (free)
> Ecolor03: 0011    (free)
> Ecolor06: 0110    (free)
> Ecolor10  1010    (free)
> Ecolor11 1011    (free)
> 
> This palette strategy may look complicated and full of constraints at first,
> but it is easy to implement and can lead to a great rendering speed. I have
> used it in sprite games in EGA and VGA in the mid-1990s.
> 
> The only complete game I still have from the 90s is a 3D game (using my own
> 320x200x256 VGA/MCGA libraries) I've programmed in 1998-1999 in Turbo Pascal.
> It used some nice optimizations such as "compiled" texture maps. It can be run
> in DosBox, but due to the heavy use of fadouts using the Bios Palette
> interrupt (INT10; AH=0B), the game is EXTREMELY slow in DosBox mode. Even in
> fullscreen mode you have painful 10-seconds transitions between moves :( Scene
> rendering used to take 1-2 seconds on a first-gen Pentium with 4mb memory.
> 
> The game was in French but I have translated some of its content to English.
> It's an expandable multilevel labyrinth game (with a single level in this
> version) with a crude scripting engine. Here's the download URL:
> http://avantrad.ca/upload/hugo/
> 
> 
> Le 2015-03-07 01:40, Richard Goedeken a écrit :
>> Hi Hugo,
>>
>> I'm glad that you like DynoSprite.  I'll definitely be writing at least one
>> game with it, though it will probably take quite a while to finish.  I've also
>> written lots of x86 assembly, though it's been mostly SIMD stuff since the
>> late 90s.
>>
>> Was there anything published with your sprite rendering code, or was it just a
>> personal project?  I've always liked this sort of software.
>>
>> Richard
>>
>> On 03/06/2015 06:03 AM, Hugo Dufort wrote:
>>> Hi Richard, I was really impressed by Dynosprite, and I have started reading
>>> the source ASM code to learn a few tricks. I hope you or other people will
>>> develop a platform game with your engine.
>>>
>>> I have developed a few fast sprite rendering algorithms (with transparency)
>>> when I was programming on the 80x86 in graphics modes using 16 and 256 colors.
>>> One of the techniques allowed a limited number of colors for the sprites and
>>> the sprite background, but the rendering loop in ASM had a single "OR"
>>> operation.
>>>
>>> Hugo
>>>
> 
> 
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> http://www.avast.com
> 
> 