Archive for February, 2008

February 25th, 2008 by nkeynes
Slow Week II: Revenge of Slow Week
Posted in Development

Real Life(tm) has been a little bit hectic lately, so there’s isn’t much to report for last week for lxdream. The render split is mostly done now, and will probably be merged back to trunk this week (as soon as I reintegrate the trans poly sorting). Unfortunately I didn’t really get any performance improvements out of it (well, I was probably a little hopeful there), but at least I didn’t lose any performance either, and it was worth doing for other reasons. Once that’s merged I’ve got a few small non-render issues to sort out, and then I’ll get back to the annoying rendering bugs…

In other news, dclinux 010605 is now hosted locally (as long as the bandwidth holds out), including a self-booting NRG image (thanks to The Gypsy), check it out on the wiki. Note that you’ll need the latest svn trunk to boot the nrg image properly.

And finally, I see that MAME now has a mostly complete AICA driver, thanks to ElSemi, kingshriek, dknute & R.Belmont. *jaw drop*. That… will _really_ help ^_^.

Trunk Changes

  • Fixed a couple of d’oh-level SH4 bugs (thanks to dknute for pointing them out)
  • Quick hack to get the dclinux nrg booting. Full update to follow soon.
February 18th, 2008 by nkeynes
Render rewrite still going
Posted in Development

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
February 10th, 2008 by nkeynes
Looking for linux (in all the wrong places?)
Posted in Development

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.

  • 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.

February 7th, 2008 by nkeynes
Rendering WIP
Posted in Development

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.