[Coco] Help with algorithm in assembly...

[Lee]

I've got it reading the original data files and converting the graphics
when it first starts up.  It only stores the converted graphics (ready for
GIME consumption) in memory.  My main reason for wanting to use the
original data files is to lessen the chance anyone will complain about me
"stealing" copyrighted information.  By using the original data files, I'm
just writing an "engine" that "plays" the original files.  Even though this
is just a "hobby" and I never plan to sell this, I don't want a "cease and
desist" letter coming my way. :)

As far as progress, I've got it rendering a level (16x12 tiles with tiles
being 16x16 pixels) in 4½ vsyncs.  I need to have a game cycle every 5
vsyncs, so I only have ½ a vsync right now to do any game logic.  Still
working on getting that down.  I don't really need to render all the tiles
every game cycle, probably only ½ that many tiles at max and only about 10
or so on most levels.  So I think it's going to work out great.  Currently
I'm taking a break from the CoCo coding and working on diving into the DOS
game's EXE and tracing through it with DosBox-X's debugger to try and
reveal some of the game's logic. That's a painstaking grueling tedious
experience, but it's already revealing some good information.

-----
Lee


On Wed, Nov 2, 2022 at 6:37 PM Mark McDougall via Coco <coco at maltedmedia.com>
wrote:

> On 17/10/2022 9:58 pm, Lee via Coco wrote:
>
> > Thanks! :)  I'm setting a palette that matches the default EGA 16-color
> > palette pretty closely.  As for pre-converting the images, I could do
> that,
> > and it certainly would make my life much easier, but the game I'm writing
> > is a clone of an existing DOS game and I'd rather be able to drop the
> > original game's data files in.  The original game's tiles are in planar
> > format, so I'm loading/converting them in memory when the game starts.
>
> I've done a number of game conversions from one platform to another and
> generally I pre-convert all the graphics data into a format more
> suitable to the target platform (in some cases - like the Neo Geo - it's
> essential because you only have ROM-based tiles).
>
> My MO is to write a PC-based utility in C that rips the graphics
> directly from the original binary and does a number of things; generates
> 1-byte-per-pixel C arrays (rotated if necessary) for easy conversion
> into multiple formats, and subsequent conversion to my current chosen
> target platform. It then renders the converted graphics on the PC for
> visual confirmation.
>
> But I can see the attraction of your approach; being able to use the
> original graphics data is kinda nice, and the limited EGA palette makes
> it pretty straightforward in this case.
>
> Looking forward to seeing what you come up with, sounds interesting!
>
> Regards,
>
> --
> Mark McDougall
> <http://retroports.blogspot.com.au>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>