[Coco] Development environment

[Hugo Dufort]

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