Another 68K Coding Challenge | page 1 2
|
---|
|
---|
| | Nixus Minimax
Posts 416 17 Feb 2018 09:48
| Gunnar von Boehn wrote:
| The NEO-GEO emulator uses 15bit colors. |
Ah, okay. In the other coding challenge you wrote: Gunnar von Boehn wrote:
| The screen buffer is 16bit hicolor. |
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6254 17 Feb 2018 10:21
| Nixus Minimax wrote:
|
Gunnar von Boehn wrote:
| The NEO-GEO emulator uses 15bit colors. |
Ah, okay. In the other coding challenge you wrote: Gunnar von Boehn wrote:
| The screen buffer is 16bit hicolor. |
|
Yes this is correct. The NEO-GEO emulator used to open a 16bit screen but used only 15bit colors. So one bit was unused all the time. We changed the emulator to open 15bit screen - this changes nothing on the picture as the used colors were all the time only 15bit. Now we can use the free bit as mask.
| |
| | Thellier Alain
Posts 143 19 Feb 2018 14:57
| >Reading the background pixel is slow and totally unneeded. I must explain a few as I was the first to propose to "read the background pixel" ( that IMHO should accelerate some 68k cpus but not the 68080 ) What i was proposing in the other thread was: using a pointer table (pointer_palette) that contain where is color n. So color0 is at current screen position and color1 color2 color3 ... color15 are in the palette So the "read background from the screen bitmap" only occurs for color0 not for all pixels Of course it add a write/read to pointer_palette for all pixels but as pointer_palette will be certainly in the cache it may still speed up the standard NEO-GEO emulator on non 68080 architectures Gunnar: You should name that "68080 Coding Challenge" :-) Alain
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6254 20 Feb 2018 09:53
| thellier alain wrote:
| What i was proposing in the other thread was: using a pointer table (pointer_palette) that contain where is color n.
|
OK, I understand what you say. This idea works but it will add the price of an extra pointer fetch.thellier alain wrote:
| it may still speed up the standard NEO-GEO emulator on non 68080 architectures
|
Yes, but we have to mind that the NEO-GEO emulator is a very costly program. A lot more expensive and CPU intensive than most AMIGA programs. Probably of all AMIGA CPUs only the 68080 has the horse power to run it at sensible speed.
| |
| | Samuel Devulder
Posts 248 20 Feb 2018 11:27
| Gunnar von Boehn wrote:
| This idea works but it will add the price of an extra pointer fetch.
|
On all amigas, memory access is a slow operation. Always prefer registers. In that algorithm you not only need to fetch the pointer from the cache which may be (relatively) fast, but you still need to update it *for every pixel*. This means that for writing a single pixel you'll have to write the pal pointer as well. So in addition of writing the real data (2bytes), you add 4 more bytes to writes (the pointer). This is 200% extra memory writes. I'd say this is slow, whatever the amiga is.
| |
|