Project 2

A place to discuss everything Dragon related that doesn't fall into the other categories.
User avatar
rolfmichelsen
Posts: 296
Joined: Wed Apr 08, 2009 8:43 pm
Location: Oslo, Norway
Contact:

Re: Project 2

Post by rolfmichelsen »

robcfg wrote: Thu Jul 22, 2021 4:34 am This is brilliant!

Looking forward to playing it :mrgreen:
I can only second that statement! Love the attention to details.
pser1
Posts: 1652
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Project 2

Post by pser1 »

Hi Steve,
sorry for being so late :-(
That project is really great stuff.
I'd love to play that game!
Your explanations are worth more than one read ;-)
thanks a lot for supporting our nice computers!
cheers!
pere
User avatar
Bosco
Posts: 330
Joined: Tue Mar 04, 2014 11:49 pm
Location: Nottingham, UK

Re: Project 2

Post by Bosco »

Thanks everyone for all the great comments and words of encouragement. You obviously all have impeccable taste. :lol:

Still deciding which task in Trello to tackle next, (so many choices) but hopefully I'll have another update fairly soon.

Also, Pere, it was a pleasure to meet you at last on Zoom last weekend. :D
pser1
Posts: 1652
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Project 2

Post by pser1 »

Hi Steve,
It was a pleasure for me too!
It is better for me to relate a face to someone, not just his name!
I use to look at the photo-reports of the UK meetings for that very same reason.
Can't wait to read more about your project!
This is going to be a great masterwork, for sure.
cheers!
User avatar
Bosco
Posts: 330
Joined: Tue Mar 04, 2014 11:49 pm
Location: Nottingham, UK

Re: Project 2

Post by Bosco »

As work on the game isn't too visual at the moment I thought instead I'd describe briefly how I'm encoding platform data for each screen. Naturally, efficient data is as important as efficient code. With this in mind, I'm encoding platforms as a series of signed 8-bit offsets which index the tile graphics in memory. This not only simplifies calculations when rendering but can also optimise tasks such as collision. Tiles which I've designated as solid all have positive offsets while tiles which the player can fall through have negative offsets. So just from loading any tile ID I can immediately either BPL or BMI (branch if plus/minus) to determine whether a tile is collidable or not. Similarly bridges are solid but can be destroyed (by bombs) so they have a zero offset and can be quickly identified using BEQ (branch if zero).

On a side note, bridges only require 12 bytes of graphics data and are rendered separately by a routine which completes the tile by jumping partway into an optimised gap tile draw routine. The same routine is also used to render blue waterfall tiles by simply loading a different value into the D register (animating wave patterns are overlayed separately). You'll also notice that the tile sequence is disjointed. The number of mid tiles varies between tile sets so positioning them at the end keeps the initial offsets consistent and the latter optional.
Attachments
Platforms.png
Platforms.png (17.92 KiB) Viewed 11211 times
User avatar
robcfg
Posts: 1527
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Re: Project 2

Post by robcfg »

Thank you for these pearls of wisdom!
User avatar
Bosco
Posts: 330
Joined: Tue Mar 04, 2014 11:49 pm
Location: Nottingham, UK

Re: Project 2

Post by Bosco »

Thanks Rob. Any wisdom in what I'm doing was learned from this group. :D
User avatar
Bosco
Posts: 330
Joined: Tue Mar 04, 2014 11:49 pm
Location: Nottingham, UK

Re: Project 2

Post by Bosco »

I thought I'd split my next project update into two parts and talk briefly about the game's text handling before moving onto the main update. Circe's font uses only five bytes per character so is small enough to encode text strings as a series of 8-bit offsets into the font graphics data. One byte can index a range of 52 characters or 10 digits, 26 letters and 16 extra characters. This approach simplifies text rendering but also sidesteps the added awkwardness of graphics which aren't power of two in size.

When calling the text rendering routine I pass it the number of characters I wish to print rather than relying on an end of string marker. Being able to print a varying number of characters from any point in a string comes in handy for all sorts of uses including scrolling messages, animating UI gauges and applications I'll discuss in the following update. One more point of interest I'll mention is that the text renderer ignores leading zeroes by continually looping (BEQ) until it loads a non-zero character offset or only one character remains to be printed. This is useful for printing player scores etc. however if preferred the text renderer can be called a few instructions further on, bypassing this behaviour altogether.

When a character is rendered I use the screen offsets 0, -32, -64, -96 and -128 to keep the index addressing range 8-bit. Text is stored as red pixels (%11) on a green background (%00) but other colour combinations are achievable by flipping bits using AND, OR, EOR and COM (see truth table below). The text renderer includes strategic NOP instructions which can be overwritten to alter the output to any desired ink/paper combination. As well as the main text renderer I also use a dedicated rendering routine for a slightly more complex drop shadow effect.

The next update will be a bit more interesting but it's useful to know how text is handled if you're following along with the project. 🙂
Attachments
Text.png
Text.png (2.61 KiB) Viewed 10595 times
sorchard
Posts: 529
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Project 2

Post by sorchard »

Hi Steve,

That's a neat way of colouring the text. Always 4 cycles if you use OR #0 as a NOP.

And there's me thinking my own method at 6 cycles was being clever ;)
Stew
User avatar
Bosco
Posts: 330
Joined: Tue Mar 04, 2014 11:49 pm
Location: Nottingham, UK

Re: Project 2

Post by Bosco »

Great suggestion Stew. That's going in. :D
Post Reply