JKKDARK
February 22nd, 2008, 19:35
The latest news about the Sega Dreamcast emulator (http://www.lxdream.org/) for Windows, Linux and Mac.
Rendering WIP (http://www.lxdream.org/news/archives/36)
I’ve started fiddling with the vertex shader, which has been fairly educational. It hasn’t actually fixed any of the bugs yet, but I’m hoping it will eventually give much better rendering accuracy. (Thanks to dknute for some good suggestions on the z-buffer problem) Unfortunately turning on the VS (even with a trivial program) gave me a big performance hit on my (admittedly relatively old) hardware, so it remains to be seen whether this will be viable for said hardware.
Also did some work to get osmesa support up and running, which is mostly done now but doesn’t quite work correctly (there’s some weird texture bugs, as well as the occasional projection matrix screwup). Unfortunately it’s also _really_ slow on any kind of real scene, so I’m not sure how much effort it’s worth spending on it at the moment[0].
Currently I’m working on reworking the renderer to use vertex buffers (or client-side arrays in the absense of VBO support), which are purported to be outrageously faster than immediate mode. We’ll see if that’s true, but even if there’s no big difference, the resultant data structures should be a lot easier to work with for processing purposes (saves traversing the tilebuffer repeatedly).
After the dust settles on that, the next priority is to fix the known outstanding blatant render bugs:
* Bug #29: Texture coordinate problems.
* Obviously wrong colours in some scenes
* Issues with misplaced (or incorrect geometry) in some scenes (the pre-render data is demonstrably correct in these cases, so it’s either a misread of the scene data (probably), or cases that need to be handled specially).
* Various hw specific issues with certain texture types (my favourite thus far is a scene that breaks on both ATI and NV but in quite different and distinct ways…)
And then on to shadow volumes (interesting), RTT (easy), pixel-level transparency sorting (hard) and all the other fun stuff ^_^.
[0] It should be possible to take just the sw rasterization engine out of mesa, and blow away the front end more or less completely. This would be a fair bit faster than it is currently, but it still probably won’t be fast enough. It also looks to involve quite a bit of work as well.
Looking for linux (in all the wrong places?) (http://www.lxdream.org/news/archives/37)
It turns out that the lc2000.iso link that was posted (btw, thanks for that! ^_^) is an earlier version of linux-dc (it identifies as running the 2.4.0-test8 kernel) than the one I’d been testing with, and it exposed a few issues that needed fixing. These are now fixed in svn, except for the keyboard issue, for which source [0] would be very helpful if anyone has it?
Unfortunately this does mean I’m still looking for the original dreamcast-linux-010605.tar.bz2 (and the associated pre-built CDI and NRG images) - so if anyone has them, or knows where to find them, please let me know. I’m quite happy to host them locally, at least until the bandwidth runs out ^_^.
Btw for the BSD fans, there was supposed to have been a live netbsd disc floating around somewhere (the link from gxemul is dead) - has anyone seen it?
Edit: Nevermind, the NetBSD 3.1 image is actually included in the main netbsd mirror… having a look at it now.
Changes
* Fix LDS/STS FPSCR/FPUL instructions to raise FPU disabled exceptions (wasn’t very well documented in the original SH4 manual)
* Fix IDE dma read looping forever if the disc was removed or failed in the middle of the operation
* Fix crash when changing maple peripherals (this one was just boneheaded)
[0] The image itself does have quite a bit of source on it, but I can’t find the associated linux-sh-dc kernel patches against 2.4.0-test8. Which, of course, is the bit I actually need…
Updated 13 Feb: I don’t need the 2.4.0 source patch anymore - turns out its not a bug, that version was just hard coded to expect the keyboard on the 4th maple port, and I had it on the 3rd. Although, it would still be good to see it for the sake of the history.
Render rewrite still going (http://www.lxdream.org/news/archives/38)
Still working on the render rewrite which is now in the lxdream-render branch (which may or may not even compile, and certainly won’t work at the moment).
The frontend stage to extract the poly+vertex data out into a nice array format is working now, and it runs in just about negligible time. Current task is to execute the rendering from the vertex buffer, which should be pretty straightforward. So… once this is done we should have a renderer which is a) much cleaner/extensible, b) much faster, and c) about the same or even less code.
If only all software engineering was like that ^_^.
Trunk Changes
* Fix inverted mouse button sense
* Fix incorrect error response size for maple get_condition buffers
* Fix keypad keycode translations
* Fix SLEEP timing fubar introduced in 0.8.3
Rendering WIP (http://www.lxdream.org/news/archives/36)
I’ve started fiddling with the vertex shader, which has been fairly educational. It hasn’t actually fixed any of the bugs yet, but I’m hoping it will eventually give much better rendering accuracy. (Thanks to dknute for some good suggestions on the z-buffer problem) Unfortunately turning on the VS (even with a trivial program) gave me a big performance hit on my (admittedly relatively old) hardware, so it remains to be seen whether this will be viable for said hardware.
Also did some work to get osmesa support up and running, which is mostly done now but doesn’t quite work correctly (there’s some weird texture bugs, as well as the occasional projection matrix screwup). Unfortunately it’s also _really_ slow on any kind of real scene, so I’m not sure how much effort it’s worth spending on it at the moment[0].
Currently I’m working on reworking the renderer to use vertex buffers (or client-side arrays in the absense of VBO support), which are purported to be outrageously faster than immediate mode. We’ll see if that’s true, but even if there’s no big difference, the resultant data structures should be a lot easier to work with for processing purposes (saves traversing the tilebuffer repeatedly).
After the dust settles on that, the next priority is to fix the known outstanding blatant render bugs:
* Bug #29: Texture coordinate problems.
* Obviously wrong colours in some scenes
* Issues with misplaced (or incorrect geometry) in some scenes (the pre-render data is demonstrably correct in these cases, so it’s either a misread of the scene data (probably), or cases that need to be handled specially).
* Various hw specific issues with certain texture types (my favourite thus far is a scene that breaks on both ATI and NV but in quite different and distinct ways…)
And then on to shadow volumes (interesting), RTT (easy), pixel-level transparency sorting (hard) and all the other fun stuff ^_^.
[0] It should be possible to take just the sw rasterization engine out of mesa, and blow away the front end more or less completely. This would be a fair bit faster than it is currently, but it still probably won’t be fast enough. It also looks to involve quite a bit of work as well.
Looking for linux (in all the wrong places?) (http://www.lxdream.org/news/archives/37)
It turns out that the lc2000.iso link that was posted (btw, thanks for that! ^_^) is an earlier version of linux-dc (it identifies as running the 2.4.0-test8 kernel) than the one I’d been testing with, and it exposed a few issues that needed fixing. These are now fixed in svn, except for the keyboard issue, for which source [0] would be very helpful if anyone has it?
Unfortunately this does mean I’m still looking for the original dreamcast-linux-010605.tar.bz2 (and the associated pre-built CDI and NRG images) - so if anyone has them, or knows where to find them, please let me know. I’m quite happy to host them locally, at least until the bandwidth runs out ^_^.
Btw for the BSD fans, there was supposed to have been a live netbsd disc floating around somewhere (the link from gxemul is dead) - has anyone seen it?
Edit: Nevermind, the NetBSD 3.1 image is actually included in the main netbsd mirror… having a look at it now.
Changes
* Fix LDS/STS FPSCR/FPUL instructions to raise FPU disabled exceptions (wasn’t very well documented in the original SH4 manual)
* Fix IDE dma read looping forever if the disc was removed or failed in the middle of the operation
* Fix crash when changing maple peripherals (this one was just boneheaded)
[0] The image itself does have quite a bit of source on it, but I can’t find the associated linux-sh-dc kernel patches against 2.4.0-test8. Which, of course, is the bit I actually need…
Updated 13 Feb: I don’t need the 2.4.0 source patch anymore - turns out its not a bug, that version was just hard coded to expect the keyboard on the 4th maple port, and I had it on the 3rd. Although, it would still be good to see it for the sake of the history.
Render rewrite still going (http://www.lxdream.org/news/archives/38)
Still working on the render rewrite which is now in the lxdream-render branch (which may or may not even compile, and certainly won’t work at the moment).
The frontend stage to extract the poly+vertex data out into a nice array format is working now, and it runs in just about negligible time. Current task is to execute the rendering from the vertex buffer, which should be pretty straightforward. So… once this is done we should have a renderer which is a) much cleaner/extensible, b) much faster, and c) about the same or even less code.
If only all software engineering was like that ^_^.
Trunk Changes
* Fix inverted mouse button sense
* Fix incorrect error response size for maple get_condition buffers
* Fix keypad keycode translations
* Fix SLEEP timing fubar introduced in 0.8.3