Doom on z80

Page 5/26
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

Par ARTRAG

Enlighted (6828)

Portrait de ARTRAG

12-09-2011, 10:18

@sarcasmic
I did just for you this special buildt of maze3d
https://sites.google.com/site/testmsx/msx2-doom/maze3d_2011_09_12.rar?attredirects=0&d=1

run the .BIN as .ROM in bluemsx emulating a turboR

Par Maggoo

Paragon (1216)

Portrait de Maggoo

12-09-2011, 15:57

anyone willing to help in thinking to a sprite scaler ?

What screen mode are you using? I'm assuming you're talking about SW sprites right? Why not just precalc the sprites in different sizes?

Par Maggoo

Paragon (1216)

Portrait de Maggoo

12-09-2011, 16:04

@sarcasmic
I did just for you this special buildt of maze3d
https://sites.google.com/site/testmsx/msx2-doom/maze3d_2011_09_12.rar?attredirects=0&d=1

run the .BIN as .ROM in bluemsx emulating a turboR

This looks great! I'm really impressed by the speed... It's moving smoothly enough for a game.

Par ARTRAG

Enlighted (6828)

Portrait de ARTRAG

12-09-2011, 17:39

The game (demo? ;-)) is in screen 5.
Precomputing sprites at different sizes is ok, but they have to be clipped too, in order to be partially visible behind corners.
Ideally each enemy should have at least 4 (8?) directions, with some frames of animation.

the use of HW sprite implies this limitation:
- one monocrome enemy at time on teh screen composed by 4 x 8 sprites == 64x128 pixel wide
- complex clipping due to the interaction with raycasting (maybe some code for screen 2 sw sprites - ZX like, could be reused here).

SW sprites
- are simpler to be integrated in the raycasting engine
- you can have more than one enemy
- they are damn slow (!)

Par viejo_archivero

Paragon (1395)

Portrait de viejo_archivero

12-09-2011, 18:30

I did just for you this special buildt of maze3d
https://sites.google.com/site/testmsx/msx2-doom/maze3d_2011_09_12.rar?attredirects=0&d=1
run the .BIN as .ROM in bluemsx emulating a turboR

Awesome.

Par Maggoo

Paragon (1216)

Portrait de Maggoo

12-09-2011, 19:41

The game (demo? ;-)) is in screen 5.
Precomputing sprites at different sizes is ok, but they have to be clipped too, in order to be partially visible behind corners.
Ideally each enemy should have at least 4 (8?) directions, with some frames of animation.

the use of HW sprite implies this limitation:
- one monocrome enemy at time on teh screen composed by 4 x 8 sprites == 64x128 pixel wide
- complex clipping due to the interaction with raycasting (maybe some code for screen 2 sw sprites - ZX like, could be reused here).

SW sprites
- are simpler to be integrated in the raycasting engine
- you can have more than one enemy
- they are damn slow (!)

I'd stay away from the HW sprite, the question of clipping alone and the color constraints make it more trouble than it's worth.

- For the sw sprite and clipping... it's easy (I think), you just copy the horizontal size you need an nothing more... It may actually go faster once they are "clipped" since the copy is smaller.
- You don't need to have the sw sprites in every single sizes.... just approximate and it will be good enough... perhaps 10 stages of zoom should do.
- Since you rebuild the entire background every time, you have the advantage of not having to use double buffering for the sprites and restore the background etc.... the entire rebuilding of the 3d background is already done anyway.
- You probably need to use logical copy for those sw sprites which are a bit slower.

Par PingPong

Prophet (3885)

Portrait de PingPong

12-09-2011, 19:51

@sarcasmic
I did just for you this special buildt of maze3d
https://sites.google.com/site/testmsx/msx2-doom/maze3d_2011_09_12.rar?attredirects=0&d=1

run the .BIN as .ROM in bluemsx emulating a turboR
@ARTRAG. how much fps you achieved on a tr? it's possible to have a msx2 build?

Par ARTRAG

Enlighted (6828)

Portrait de ARTRAG

12-09-2011, 20:21

This last version does about 20 FPS according to the complexity of the scene, but I should implement a true FPS counter ;-)

For an msx2 version I should revert some lmul to calls, it is an hard work as, even if they are not a lot, they are spread in many files.

[edit]
just measured: it gives an average 18,45 Fps (60Hz)

Par PingPong

Prophet (3885)

Portrait de PingPong

12-09-2011, 20:40

This last version does about 20 FPS according to the complexity of the scene, but I should implement a true FPS counter ;-)

For an msx2 version I should revert some lmul to calls, it is an hard work as, even if they are not a lot, they are spread in many files.

i'm surprised about this fps. why the vdp is not a bottleneck at this speed?
Does it not take too much time to draw the screen?

Par ARTRAG

Enlighted (6828)

Portrait de ARTRAG

12-09-2011, 20:59

No, but it is due to some tricks:
- the code draws only 2xN color boxes
- the code draws only differences between frames

This latter detail is possible only thanks to the fact that walls are flat
Anyway, adding RLE encoded textures on some walls should work as well without drastic losses in the frame rate

Page 5/26
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10