3D raycasting

ページ 15/16
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16

By mars2000you

Enlighted (6346)

mars2000you さんの画像

05-02-2012, 13:30

Version 2.8.3 beta is here :

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

By Manuel

Ascended (19060)

Manuel さんの画像

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 (6891)

ARTRAG さんの画像

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 (6346)

mars2000you さんの画像

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 (6891)

ARTRAG さんの画像

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 (492)

wouter_ さんの画像

05-02-2012, 19:33

3) The mul opcode in R800 has wrong final flags &nbspCryingthe 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 (6891)

ARTRAG さんの画像

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 (6346)

mars2000you さんの画像

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 (6891)

ARTRAG さんの画像

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 (6891)

ARTRAG さんの画像

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

ページ 15/16
8 | 9 | 10 | 11 | 12 | 13 | 14 | | 16