3 ms·

An Old Problem Meets Its Timely Demise

127 points by Fzzr 13y ago

gatehouse 13y ago
Mental conversion between binary, octal, decimal, and hex is a minefield.
lukecampbell 13y ago
If anyone wants to go digging through the Nintendo GX API, the link is below. [1]: http://morukutsuland.free.fr/data/GX.pdf http://morukutsuland.free.fr/data/GX.pdf
Maxious 13y ago
> Another candidate for "why you shouldn't pay programmers per line of code" > https://code.google.com/p/dolphin-emu/source/detail?r=ed67d1ae2f9693ed42867a2e79b7cae4427574e3 https://code.google.com/p/dolphin-emu/source/detail?r=ed67d1... #2charsfix > https://twitter.com/delroth_/status/419782330354380800 https://twitter.com/delroth_/status/419782330354380800
Danieru 13y ago
One thing I noticed when contributing to PPSSPP was now familiar the programmers were with bits. Bit shifts, masks, bitwise ands against integers, lots of 'em. I saw more complex bit manipulation in the user input handling than I remember seeing in linux's task struct handling! I don't think the programmers were showing off, just they've become familiar with bits on a level beyond normal. Like how the linux guys are familiar with double star pointers. On that note I would like to encourage you the reader to contribute to an emulator. They are an intertesting problem space similar to a compiler's backend, but with fewer unit tests.
- fake-name 13y ago
  It's the familiarity thing, definitely. I do a lot of embedded MCU work, which involves so much bit-twiddling (all IO is through mem-mapped peripherals) that it's spilling over into other work I do. If I need to shove around a bunch of boolean flags, I'll probably use a int, because the boolean operations required to access the separate bits are basically autonomic at this point for me.
corysama 13y ago
Way back on the original Xbox and PlayStation2, the framebuffer and the textures were in the same memory space. And coincidentally, because you had complete control over the machine, you could construct a texture using any memory address --including that of the framebuffer! This was very not recommended. Both the internal memory layouts and the order-of-operations of memory reads and writes from different pixel operations were explicitly undefined in every hardware graphics API ever so that different GPUs could be free to have wildly different implementations. Here are some examples: http://www.youtube.com/watch?v=ZJU_CO6gRfs http://www.youtube.com/watch?v=ZJU_CO6gRfs and http://www.g-truc.net/post-0597.html http://www.g-truc.net/post-0597.html On the consoles, the memory formats and layouts were well defined, but the order of operations were not. And indeed, if you tried to draw anything that wasn't a pointless memcpy(src, src, sizeof(src)) while using the framebuffer as a source texture, you would get random, rectangular and z-shaped (morton order) glitches because of out-of-order operations stemming from the aliased source and dest buffers. However... My goal was a blurry, streaky, screen distortion effect in the weapon trails --to look like the blades were so awesome they caused refraction by cutting the air ;) I found that by sampling the framebuffer from four locations along the weapon's line of motion, the glitches were blurred and streaked out to the point that they really were not objectionable :D To do the effect according to the spec (and without glitches) I would have had to copy the whole framebuffer to a temp buffer. That would have been simply too expensive for such a small visual difference. What did ship looked great and the framebuffer-feedback feature added effectively zero cost. But, I felt kinda bad for future (now long past) emulator writers who would later try to support my out-of-spec use of the hardware which is simply not allowed by desktop APIs. (AMD's Mantle might expose it. We'll see...)
- thristian 13y ago
  That sounds like a neat hack. I don't suppose you could mention the name of the game, or link to some YouTube footage of the weapon-trail effect in action?
  - corysama 13y ago
    This is the best I can find. Be sure to go 720p. http://www.youtube.com/watch?v=MUbkdt37LJc&t=15m25s http://www.youtube.com/watch?v=MUbkdt37LJc&t=15m25s Unfortunately, the artists tuned the effect to be really subtle and it's hard to see it through the compression. When the axe is on fire, the flames are using the effect to do heat distortion as well.

127 points by Fzzr 13y ago

Mental conversion between binary, octal, decimal, and hex is a minefield.

If anyone wants to go digging through the Nintendo GX API, the link is below. [1]: http://morukutsuland.free.fr/data/GX.pdf http://morukutsuland.free.fr/data/GX.pdf

Maxious 13y ago

> Another candidate for "why you shouldn't pay programmers per line of code" > https://code.google.com/p/dolphin-emu/source/detail?r=ed67d1ae2f9693ed42867a2e79b7cae4427574e3 https://code.google.com/p/dolphin-emu/source/detail?r=ed67d1... #2charsfix > https://twitter.com/delroth_/status/419782330354380800 https://twitter.com/delroth_/status/419782330354380800

Danieru 13y ago

One thing I noticed when contributing to PPSSPP was now familiar the programmers were with bits. Bit shifts, masks, bitwise ands against integers, lots of 'em. I saw more complex bit manipulation in the user input handling than I remember seeing in linux's task struct handling! I don't think the programmers were showing off, just they've become familiar with bits on a level beyond normal. Like how the linux guys are familiar with double star pointers. On that note I would like to encourage you the reader to contribute to an emulator. They are an intertesting problem space similar to a compiler's backend, but with fewer unit tests.

fake-name 13y ago
It's the familiarity thing, definitely. I do a lot of embedded MCU work, which involves so much bit-twiddling (all IO is through mem-mapped peripherals) that it's spilling over into other work I do. If I need to shove around a bunch of boolean flags, I'll probably use a int, because the boolean operations required to access the separate bits are basically autonomic at this point for me.

corysama 13y ago

Way back on the original Xbox and PlayStation2, the framebuffer and the textures were in the same memory space. And coincidentally, because you had complete control over the machine, you could construct a texture using any memory address --including that of the framebuffer! This was very not recommended. Both the internal memory layouts and the order-of-operations of memory reads and writes from different pixel operations were explicitly undefined in every hardware graphics API ever so that different GPUs could be free to have wildly different implementations. Here are some examples: http://www.youtube.com/watch?v=ZJU_CO6gRfs http://www.youtube.com/watch?v=ZJU_CO6gRfs and http://www.g-truc.net/post-0597.html http://www.g-truc.net/post-0597.html On the consoles, the memory formats and layouts were well defined, but the order of operations were not. And indeed, if you tried to draw anything that wasn't a pointless memcpy(src, src, sizeof(src)) while using the framebuffer as a source texture, you would get random, rectangular and z-shaped (morton order) glitches because of out-of-order operations stemming from the aliased source and dest buffers. However... My goal was a blurry, streaky, screen distortion effect in the weapon trails --to look like the blades were so awesome they caused refraction by cutting the air ;) I found that by sampling the framebuffer from four locations along the weapon's line of motion, the glitches were blurred and streaked out to the point that they really were not objectionable :D To do the effect according to the spec (and without glitches) I would have had to copy the whole framebuffer to a temp buffer. That would have been simply too expensive for such a small visual difference. What did ship looked great and the framebuffer-feedback feature added effectively zero cost. But, I felt kinda bad for future (now long past) emulator writers who would later try to support my out-of-spec use of the hardware which is simply not allowed by desktop APIs. (AMD's Mantle might expose it. We'll see...)

thristian 13y ago
That sounds like a neat hack. I don't suppose you could mention the name of the game, or link to some YouTube footage of the weapon-trail effect in action?
- corysama 13y ago
  This is the best I can find. Be sure to go 720p. http://www.youtube.com/watch?v=MUbkdt37LJc&t=15m25s http://www.youtube.com/watch?v=MUbkdt37LJc&t=15m25s Unfortunately, the artists tuned the effect to be really subtle and it's hard to see it through the compression. When the axe is on fire, the flames are using the effect to do heat distortion as well.