msx-karts 1st playable demo

Page 3/7
1 | 2 | | 4 | 5 | 6 | 7

By syn

Prophet (2065)

syn's picture

23-09-2020, 16:22

OMG fantastic.. 4 PLAYER ACTION!!! this looks very promissing. I hope you can keep the speed once you've added all the game logic/sound etc...

By Pencioner

Scribe (1462)

Pencioner's picture

23-09-2020, 16:27

Wha i think that maybe not a racing, but a 3d tank battle multiplayer game could be done with this engine?

By albs_br

Champion (339)

albs_br's picture

23-09-2020, 16:33

One of the characters driving the kart MUST be a penguim! Cool

By salutte

Master (137)

salutte's picture

23-09-2020, 17:00

albs_br wrote:

One of the characters driving the kart MUST be a penguim! Cool

Absolutely! That was my first though too!
But as of now I haven't been able to portray a penguin on a kart from behind... YET!

By salutte

Master (137)

salutte's picture

23-09-2020, 17:08

ARTRAG wrote:

Awesome, the speed is amazing! Updating the sole color table is a winning strategy. The 4x1 resolution fits very well in this slant perspective. Greetings!

Thanks!! the 4x1 resolution is absolute key! And to save a few extra cycles I use 4x2 on the bottom part of the view. I must say that the part I am happiest about is that the code that renders the 4x1 part is just a large number of consecutive:

pop de
add hl, de
outi

By salutte

Master (137)

salutte's picture

23-09-2020, 17:13

Pencioner wrote:

Wha i think that maybe not a racing, but a 3d tank battle multiplayer game could be done with this engine?

it should be possible, definitely, a 3D version of tanks... actually I did one as my engineering thesis Smile But I have not calculated yet where you need to display a sprite given its 3d location and the viewport orientation, so enemies can not be yet displayed. This should be the next step!

By inchl

Resident (41)

inchl's picture

23-09-2020, 17:26

Very nice demo!
I was wondering how are you planning to handle interrupts (vdp/moonsound) ? Since you are using the stack (very smart!) you cannot enable the interrupt when the draw routine is executing. Is that routine completed within one interrupt?

By salutte

Master (137)

salutte's picture

23-09-2020, 17:33

inchl wrote:

Very nice demo!
I was wondering how are you planning to handle interrupts (vdp/moonsound) ? Since you are using the stack (very smart!) you cannot enable the interrupt when the draw routine is executing. Is that routine completed within one interrupt?

Thanks! The update routine is split in chunks of 8 characters, interruptions can be called in between chunks, albeit the demo never enables interrupts. I'm was very worried about tearing happening due to uncontrolled interruptions, but I think it should not be very visible.

By inchl

Resident (41)

inchl's picture

23-09-2020, 17:44

I still need to dive more into your code! Fun it's both asm and c.

Correct me if I am wrong, but I assume that you are using the pop de/add hl,de/outi routine for applying the x,y translation over the street bitmap and setting reg HL to the selected rotation angle table?

What vdp data are you updating? Is color spill still an issue?

By salutte

Master (137)

salutte's picture

23-09-2020, 18:13

The code is quite ugly Smile

I only update the color table, and I set the pattern in a way that each write to the VDP writes exactly 2 superpixels (of 4x1 each), so no colorspill. It is done in a way that if I write 0xAB, the first 4x1 pixels get the color 0xA, and the second 4x1 pixels get the color 0xB.

The map is 64x64 pixels, it is stored in a somewhat weird way: 1st byte contains two times the 1st pixel, the 2nd byte contains once the 1st pixel and once the 2nd pixel (immediately left from the 1st), the 3rd byte contains twice the 2nd pixel, etc... So if pixels starting from the left corner are colored 0, 1, 2, 3, ... the map is stored as:
0x00, 0x01, 0x11, 0x12, 0x22, 0x23, etc....

This means that the map takes 8kbytes (64x64x2), but we store 4 copies of the map, one for each 90º rotation.
As a result, the map occupies 4 segments, of the 256 available in ASCII8 mapper.

The tables are basically a set of offsets (16 bits), and are precalculated in two areas. the 4x1 offset is 32 lines x 32 characters, and takes 2kbytes. the offsets for the 4x2 part is also 32 lines x 32 characters, so another 2kbyes. Full lookup tables for a specific view is 4 kbytes.

Each big map pixel is divided in 16 possible subpixels (4 horizontal subdivisions, and 4 vertical subdivisions), and we encode 16 angles (from -45º to +39.375º). We need one lookup table for each combination: 256 combinations, 1024 kbyes (128 segments).

The precalculated a lookup tables only cover for 90º, this is the reason we need to encode the map rotated 4 times.

When rendering, we use the mapper to map the map to 0x8000 and another copy to 0xA000, so beyond the horizon we see a repetition of the original map. We map the current quadrant of the map.

Then, the lookup table corresponding to the current subpixel and angle is mapped inside the 0x6000 segment.

At the start of the copying rutine, HL points to the current map coordinate that contains twice the pixel value. SP points to the beginning of the lookup table, and we start to run the code that combines the current map coordinate (on HL) with the lookup that calculates the perspective.

That's the very rough explanation. There a few oddities more, but they are not really relevant to the engine.

Page 3/7
1 | 2 | | 4 | 5 | 6 | 7