Screen construction in isometric games

[ervin]

Hi folks.

Something I've wondered about for a long time is how screens are constructed in isometric games.
For example, when you walk into a new room in Head Over Heels, I'd love to be able to see the screen being drawn and all the objects being placed. It would be a very interesting learning exercise.

I presume that all inks are set to black, the screen is constructed, then all the inks are set to the appropriate colours.
And this is to hide the construction phase.
But it's so interesting to see it happening in something like Last Ninja on the C64, though that game's screen construction is very slow.

I wonder if it's possible to patch a game like HoH, Batman, Knightlore or Alien 8 to skip the code that sets all inks to black when entering a new screen...

[Fessor]

Here is a great explanation about the Filmation-Engine available: http://retrospec.sgn.net/users/nwalker/filmation/

[roudoudou]

I wonder if it's possible to patch a game like HoH, Batman, Knightlore or Alien 8 to skip the code that sets all inks to black when entering a new screen...

easy with winape and a breakpoint on ink modification

[ervin]

Here is a great explanation about the Filmation-Engine available: http://retrospec.sgn.net/users/nwalker/filmation/

That's tremendous, thanks!

[ervin]

easy with winape and a breakpoint on ink modification

I'd love to have a try. 
What sort of code would I need to look for, in order to find ink modification code?

[roudoudou]

in fact it would be useless 


the screen is built in another buffer in #9000 then copied to the real screen without changing INK, so there is no "inks to black" at all


here is some capture of the memory

[ervin]

Oh wow... ok.
That's a shame.

Nonetheless, those screenshots you posted are *very* interesting.
Thanks for taking the time to do those.

[AMSDOS]

Could the Screen Blanking process be using the CTRC to hide the drawing process and simply use it to again to when complete?


A BASIC example of the process:

Code: [Select]

10 MODE 0
20 OUT &BC00,1:OUT &BD00,0
30 LOCATE 10,10:PRINT"A"
40 CALL &BB18
50 OUT &BC00,1:OUT &BD00,40


[andycadley]

Could the Screen Blanking process be using the CTRC to hide the drawing process and simply use it to again to when complete?


A BASIC example of the process:

Code: [Select]

10 MODE 0
20 OUT &BC00,1:OUT &BD00,0
30 LOCATE 10,10:PRINT"A"
40 CALL &BB18
50 OUT &BC00,1:OUT &BD00,40


It would be a way to do it, although generally isn't. There are lots of other reasons for using a back buffer, particularly that you can lay it out as a more idealised version of screen memory and thus avoid having to deal with screen addressing weirdness at the same time as drawing tiles.

[SyX]

Something I've wondered about for a long time is how screens are constructed in isometric games.
For example, when you walk into a new room in Head Over Heels, I'd love to be able to see the screen being drawn and all the objects being placed. It would be a very interesting learning exercise.

I presume that all inks are set to black, the screen is constructed, then all the inks are set to the appropriate colours.
And this is to hide the construction phase.

I wonder if it's possible to patch a game like HoH, Batman, Knightlore or Alien 8 to skip the code that sets all inks to black when entering a new screen...

Well, my favorites CPC games are Batman and HoH. And because that I disassembled those games a lot of moons ago. Jon Ritman's isometric code is well optimized and it doesn't need an extra buffer. Both games work exactly as you said, they put black inks and then build the screen. Of course, both games are very easy to patch for using other palette than a black one. For patching those games, open WinApe, load the games (I used the cpc-power original floppy versions):

Code: [Select]

In Batman change the memory address $032A from $08 to $07 (for using the palette number 7, for example).
In Head Over Heels change the memory address $04F9 from $08 to $07 (in the same way than before).
And you will see how the screen is built, but as I said the Ritman code for drawing is well optimized and I don't know if it would be helpful for you:

It would be a way to do it, although generally isn't. There are lots of other reasons for using a back buffer, particularly that you can lay it out as a more idealised version of screen memory and thus avoid having to deal with screen addressing weirdness at the same time as drawing tiles.

I would love to hear a few of those reasons for using a back buffer.

Because for me, the only reason in a CPC game for using a back buffer so big as the actual screen, it is because that game is an speccy port. A decent CPC game that need so big buffer, it would use a double buffer instead (saving the stupid LDI/LDIR copy pass) and a rupture for splitting the HUD from the game area.

Knightlore and Alien 8 are speccy ports. They use the typical Ultimate routine of drawing the graphics downside for hoping the raster only will catch once... not in CPC, mate, because you need to copy more data. And the screen is dumped from the buffer to the video ram using LDIRs. All that make those games super slow if you compare with Ritman's games. Even the sprite routine could be a lot better and use a minimal ram buffer for preparing the sprites in those Ultimate games.

[ervin]

Thanks Syx.
That's really fantastic information.
I'm impressed with how HoH constructs the screen.
(HoH is also my favourite CPC game of all time).

Considering the z-ordering that would have to occur when positioning objects on the screen, I'm surprised (and *very* impressed) by what John Ritman did.

I wonder if Ultimate's games can be patched to use stack-based screen-redraw instead of LDI-based.
How would I go about disassembling the code?
(And does the disassembler tell us what the execution address is?)

[EDIT] It's really cool playing HoH with the small patch.
Very weird to see the screen being drawn, but fascinating.
Interesting how all the colours revert to some sort of defaults when changing screen, and then change to the correct colours for the screen being entered.

[Fessor]

If you know the Addresses (Load-Address, Entry-Point) you can use ghidra to REassemble binarys and try to reconstruct a sourcefile.
https://ghidra-sre.org/

[ervin]

If you know the Addresses (Load-Address, Entry-Point) you can use ghidra to REassemble binarys and try to reconstruct a sourcefile.
https://ghidra-sre.org/

Thanks!

[SyX]

You are welcome @ervin

If I remember well, Batman and HoH use exactly the same algorithm for building the screens. HoH has minor optimizations, but nothing too fancy, Ritman was most focused in good data structures than hyperfast routines.

And the PCW version of those games are based in the CPC code, too. Load HoH in the CP/M Box emulator, go to the debugger and change the value in the RAM address $051D from $C9 to $00. And you will see the same effect over the PCW version. This version has a nice extra, the double screens are in the native PCW resolution, the equivalent to mode 2 in CPC; and they look superb.

Considering the z-ordering that would have to occur when positioning objects on the screen, I'm surprised (and *very* > impressed) by what John Ritman did.

If you change the WinApe timing (Settings > General) to the minimum (5%), you will see how take more time when the z-ordering is more complex, for example, in that first screen when the draw routine has to draw the right door over the floor.

I wonder if Ultimate's games can be patched to use stack-based screen-redraw instead of LDI-based.

Sure, and even having a nice unrolled LDI sequence should help something with the speed. If I remember well, there was enough space for it.

How would I go about disassembling the code?
(And does the disassembler tell us what the execution address is?)

For a lot of things, you can use the WinApe debugger, that is good enough for researching algorithms fast. I used for example for making the list with games using hardware scroll.

But, in the old days, I used dz80 or something like that, but it was a very boring and time consuming task, because you need to write the address with code and data in a text file for disassembly the binary better. Later I discovered the old ms dos free version of IDA, the one that supported z80, and after using an interactive disassembler, you will never go back to the old way. Those days, as Fessor recommended, the best option is using Ghidra, because it is open source and very active... and it doesn't cost a fortune like IDA

But in the case of using a disassembler, even if the most recommendable way would be to discover the loading and execution address. There is a easy and fast way, load the game in WinApe, start the game, then go to the debugger, save all the memory to a file and write in a paper the PC address, where the screen is, if interrupts were enabled, ... Load that file in the disassembler and set the start address for disassembling the code from the PC address that you wrote before. Remember that if a game uses interrupts, the interrupt handler would be in $0038. Mark places with data... And then go on, after a while you will be able to understand and see which bytes sequences are code: $C9 (RET), $C3 xx xx (JP $xxxx), $CD xx xx (CALL $xxxx), ...

[ervin]

Thank you Syx!
REALLY great info!
One day when I have some spare time, I might look into that LDI sequence.

[SyX]

One day when I have some spare time, I might look into that LDI sequence.

Maybe by that day, we have a CPC emulator that includes more features for helping with boring disassembly tasks. Something in the line of the memory trace dumps used by Skoolkit or the advanced disassembler/profiler included in emulators like Emulicious. Although for example, a way of using breakpoints to machine events like when the tape or floppy motor stop, it could help to automatize things like finding the execution address

[SyX]

And looking in my folder of isometric games research, I found a document from Jon Ritman explaining a few interesting things about his engine to one of the guys that made an HoH remake in the middle of last decade. I am going to attached it to this thread just in case it is not well known.

[ervin]

And looking in my folder of isometric games research, I found a document from Jon Ritman explaining a few interesting things about his engine to one of the guys that made an HoH remake in the middle of last decade. I am going to attached it to this thread just in case it is not well known.

Thanks for the pdf - it's *very* interesting.
There are some techniques in there I would never have thought of, like splitting tall objects. Very clever.

Yes, that remake was absolutely fantastic.
It was very generous of Jon to discuss his techniques like that.

[dthrone]

Nice doc!