Today I'll talk about some stuff that I hate about how the DS 3D hardware works. One of the problems with DS vertex submission, its that they are sent in fixed point, either 1.3.12 (16b per vertex) or 1.3.6 (10b per vertex). What that means, is that the you have signed numbers, with a integer range of [-8,8], and a fractional part of either 4096 parts a whole number (16b vertexes), or either 64 whole parts (10b vertexes). The joy of ancient hardware, today.
So, if you want to define bigger objects than 16 units height/width/depth, or simply, and object that is not in this 16x16x16 cube, what has to be done? Transformations come to the rescue. So, before you send a vertex/es, you just supply one or various transforms to the ds "transform unit" (it's just a matrix stack) that, for example will double your vertex positions. Even if I find this a shitty way to work (and more important, I thought this type of severely limited hardware dissapeared over a decade ago), it's not the worst part.
The worst part, is that this transform changes are permitted INSIDE the vertex submission list, so it's quite cpu/gpu intensive to emulate this behavoiur. Probably some caching will help a lot here, atleast for games that do not modify display lists while in game.
So, my first implementation of the DS 3D gpu didn't support changing some parameters inside a "vertex submission block". As an example, I'll just show what supporting that fixed:
So, if you want to define bigger objects than 16 units height/width/depth, or simply, and object that is not in this 16x16x16 cube, what has to be done? Transformations come to the rescue. So, before you send a vertex/es, you just supply one or various transforms to the ds "transform unit" (it's just a matrix stack) that, for example will double your vertex positions. Even if I find this a shitty way to work (and more important, I thought this type of severely limited hardware dissapeared over a decade ago), it's not the worst part.
The worst part, is that this transform changes are permitted INSIDE the vertex submission list, so it's quite cpu/gpu intensive to emulate this behavoiur. Probably some caching will help a lot here, atleast for games that do not modify display lists while in game.
So, my first implementation of the DS 3D gpu didn't support changing some parameters inside a "vertex submission block". As an example, I'll just show what supporting that fixed:
As usual, the left one is the one with the bug, the right one is fixed :)
Lately I've not been able to work that much on desmume, so the progress is being slow, but didn't stop.
Lately I've not been able to work that much on desmume, so the progress is being slow, but didn't stop.
3 comments:
great work man
that's very nice!!!!
I think you try too hard trying to explain it to us dumbies....Cos I think unless they have some reasonalby good understanding of 3D Geometry and that (I even feel stupid now), you sound like you're from another world ;)
Gah smart pplz, I so dumb....I work with Flash, I no dumb there XD
The reason of being so detailed, isn't making people feel dumb :P
The main reason, is because I've some coder friends that actually enjoy detailed change explanations. And, personally, I prefer to write these changes down in a somewhat detailed manner, for those writing DS emulators in the future, as they will get a not technical but practical explanation of how the DS works :)
Post a Comment