3D raycasting | MSX Resource Center (Page 15/16)

By mars2000you

Enlighted (6432)

05-02-2012, 13:30

Version 2.8.3 beta is here :

vik.cc/bluemsx/blueforum/viewtopic.php?t=1841

By Manuel

Ascended (19303)

05-02-2012, 14:04

ARTRAG: by the way, you really shouldn't adjust your MSX code in order to workaround emulator bugs. Instead, tell emulator authors to fix their emulators and use beta versions of them...

By ARTRAG

Enlighted (6932)

05-02-2012, 14:28

Developing on emulators impiles you have to live with them...
Anyway Openmsx works perfectly, so simply I stopped to use Bluemsx for this project

By mars2000you

Enlighted (6432)

05-02-2012, 14:57

Developing on emulators impiles you have to live with them...
Anyway Openmsx works perfectly, so simply I stopped to use Bluemsx for this project

I can understand that, but giving a wrong indication about an emulator is not correct, especially because blueMSX 2.8.3 beta includes this :

"fixed ARTRAGs VDP command engine bug"

By ARTRAG

Enlighted (6932)

05-02-2012, 15:32

humm... reading notes for 2.8.3 beta it appears to have all typical problems of beta versions.
ATM it is unsuitable for TR development, sorry.
I've enough problems of my own to try to cope also with emulation glitches.

I'll wait for the stable release.

By wouter_

Champion (508)

05-02-2012, 19:33

3) The mul opcode in R800 has wrong final flags &nbspthe problem has been avoided not using these flags)

I just checked the mz3d2 source code (I originally wrote that routine) ... the code still depends on the correct C-flag after a R800 MULUW instruction. It's needed when a 'detailed' wall texture is zoomed bigger than the screen height (there are separate routines for more detailed and less detailed textues, also depending on the zoom level). Though it's possible that in the current demo (by luck) the bug doesn't trigger (often).

I also checked the source code of the latest blueMSX snapshot and the MULUW bug _is_ still present. But it's also easy to fix: blueMSX developers, compare the blueMSX and openMSX source code and copy the behavior of the C-flag for the MULUB and MULUW instructions (bluemsx/Src/Z80/R800.c line 308 and 317, openmsx/src/cpu/CPUCore.cc line 4161 and 4179).

By ARTRAG

Enlighted (6932)

05-02-2012, 23:01

I enabled again the tests on the C flag after mul
https://sites.google.com/site/testmsx/msx2-doom/botsdemo.dsk...
mars2000you, this time the code will recognise the bug and stop its execution
you can use this .dsk to test your bluemsx WIP

PS
If you look for the animated robot turn right as soon the game starts

By mars2000you

Enlighted (6432)

05-02-2012, 23:39

I guess Daniel Vik will update the emulator when he will find time for that.

For the blueMSX users, I give here again the links to the demo.

To see the demo on blueMSX 2.8.3 beta, try this version :
https://sites.google.com/site/testmsx/msx2-doom/botsdemo.dsk?revision=1

The more recent version is here :
https://sites.google.com/site/testmsx/msx2-doom/botsdemo.dsk?revision=2
As there is a bug in blueMSX, it will not work.

By ARTRAG

Enlighted (6932)

06-02-2012, 00:08

Note that under revision 1 the code does not test for bugs in the r800 emulation at startup, but in any case, the error in bluemsx will affect the scalers causing time by time the wrong subroutine to be called...
This means that some columns in complex textures could appear wrong when seen from very close

By ARTRAG

Enlighted (6932)

06-02-2012, 00:34

mars, just to close the list, try also this (the very early rom version of the raycaster)
https://sites.google.com/site/testmsx/msx2-doom/D%7BSCC%7D.r...

On bluemsx it works about 3 times faster than the real thing, while openmsx and real HW add wait cycles each time the R800 accesses to charts plugged in external slots