Retro 2D palette cycling?
Started by SamuraiCrow, Feb 28 2010 11:50 PM
11 replies to this topic
#1
Posted 28 February 2010 - 11:50 PM
I'm digging out an old Worms/Scorched Earth/Artillary War style game project and trying to port it to the PC/Mac/Linux from the old classic Amiga computers. I've got permission and source code from the author and if I can get it to work on the modern desktop machines, I'll try my hand at porting down to smartphones and so on.
Under OpenGL I was hoping to be able to blit to the screen buffer from a bigger-than-screen-size texture or PBO stored as an 8-bit resolution. If palettes were unsupported, I'd use a fragment shader based on a greyscale background image colorization algorithm by indexing the light intensity into a 1D texture to emulate texture mapping. Using the aforementioned shader would be preferable since I'd be able to emulate the high- or true-color gradient shaded backdrops that the Amiga chipset made famous.
I've looked into using SDL but the palette support on the 8-bit modes are not good enough since it uses only software rendering. If I used SDL, I'd end up writing my own CPU blitting software renderer anyway, which somewhat defeats the purpose of using a rendering library in the first place. Also, I think it depends on the hardware supporting palettes internally.
I've looked at SFML also. It supports 8-bit screen resolutions but automates the palette selection to the point that I cannot manipulate the palette for cycling effects.
I'm now looking at the 2D graphics drivers present in Irrlicht. I like that they support more than one backend but still no palette support and all of the resolutions are 16 bits-per-pixel or more. No greyscale mode supported.
Is it possible that the old Amiga still does something that a modern system cannot do without running emulation code on the CPU? I thought fragment shaders could do everything I needed. :wallbash:
Please advise.
Under OpenGL I was hoping to be able to blit to the screen buffer from a bigger-than-screen-size texture or PBO stored as an 8-bit resolution. If palettes were unsupported, I'd use a fragment shader based on a greyscale background image colorization algorithm by indexing the light intensity into a 1D texture to emulate texture mapping. Using the aforementioned shader would be preferable since I'd be able to emulate the high- or true-color gradient shaded backdrops that the Amiga chipset made famous.
I've looked into using SDL but the palette support on the 8-bit modes are not good enough since it uses only software rendering. If I used SDL, I'd end up writing my own CPU blitting software renderer anyway, which somewhat defeats the purpose of using a rendering library in the first place. Also, I think it depends on the hardware supporting palettes internally.
I've looked at SFML also. It supports 8-bit screen resolutions but automates the palette selection to the point that I cannot manipulate the palette for cycling effects.
I'm now looking at the 2D graphics drivers present in Irrlicht. I like that they support more than one backend but still no palette support and all of the resolutions are 16 bits-per-pixel or more. No greyscale mode supported.
Is it possible that the old Amiga still does something that a modern system cannot do without running emulation code on the CPU? I thought fragment shaders could do everything I needed. :wallbash:
Please advise.
#3
Posted 01 March 2010 - 02:08 AM
I don't quite get what you're talking about with the grayscale colorization thing, but I don't think you need a literally grayscale render target. You could just use a full-color render target but only use one channel of it...say the red channel, arbitrarily. It might be wasteful of memory but if the hardware has no single-channel format it'll still work.
reedbeta.com - developer blog, OpenGL demos, and other projects
#4
Posted 01 March 2010 - 01:42 PM
Why not just convert the sprites to full color animations?
#5
Posted 01 March 2010 - 05:49 PM
geon said:
Why not just convert the sprites to full color animations?
@Reedbeta
I've been looking into the 16-bit floating point format with a single channel of red in Irrlicht and I think that will work fine. It'll take twice as much memory for a large texture but so what. At least it will work.
@everyone
Thanks for your input!
#6
Posted 01 March 2010 - 09:24 PM
SamuraiCrow said:
I've been looking into the 16-bit floating point format with a single channel of red in Irrlicht and I think that will work fine. It'll take twice as much memory for a large texture but so what. At least it will work.
That sounds fine as long as the hardware has the R16f format, but if you don't need 16 bits of precision you may want to provide a further fallback to RGBA8 in case they don't have the floating point format. Even more memory wastage but it will work on older hardware.
reedbeta.com - developer blog, OpenGL demos, and other projects
#8
Posted 01 March 2010 - 09:59 PM
@JarkkoL
According to your website you've got Windows supported under Spin-X. For now I only need Mac support and I'll be able to use it since I don't have a Windows machine any more.
-edit-
I won't be able to use it anyway because the game isn't a GPL compatible license.
According to your website you've got Windows supported under Spin-X. For now I only need Mac support and I'll be able to use it since I don't have a Windows machine any more.
-edit-
I won't be able to use it anyway because the game isn't a GPL compatible license.
#9
Posted 01 March 2010 - 10:05 PM
@Reedbeta
Ok. I'll remember that but I doubt it will work on older hardware anyway since I'll need render-to-texture support to create the 2D scene.
Ok. I'll remember that but I doubt it will work on older hardware anyway since I'll need render-to-texture support to create the 2D scene.
#10
Posted 01 March 2010 - 10:21 PM
Yup, it runs only under windows at the moment, although you can use gcc as well, but it's not much use for you. I would suggest using the ARGB32 format like Reedbeta suggested since it's supported by all HW. You can render to texture in old hardware as well. IIRC, I used to render to texture in TNT2, which is like 10 years old HW (:
#11
Posted 01 March 2010 - 11:39 PM
Wouldn't it just be easier to rewrite it? Since you're making heavy use of the GPU, you could end up doing far more sophisticated things such as rendering the levels using the built in noise functions, texture splatting, per-pixel lighting, particle weather effects, etc...
Or is this just to satisfy one's nostalgia? :)
Or is this just to satisfy one's nostalgia? :)
http://www.nutty.ca - Being a nut has its advantages.
#12
Posted 02 March 2010 - 04:44 PM
@TheNut
I'll probably end up rewriting the game anyway but was hoping to be able to reuse some of the code in my BASIC compiler in the runtime library. I'm hoping to bridge the gap between the Amiga chipsets and modern hardware with high-performance emulation code.
If somebody wanted to write a version that would satisfy their nostalgia, they could have downloaded AmosPro for free, downloaded an Amiga emulator for cheap, and rewritten using the Amiga chipset emulation in the emulator. I might someday write an AGA chipset version of the game just for kicks but I don't expect to make any money off of the Amiga version any more.
I'll probably end up rewriting the game anyway but was hoping to be able to reuse some of the code in my BASIC compiler in the runtime library. I'm hoping to bridge the gap between the Amiga chipsets and modern hardware with high-performance emulation code.
If somebody wanted to write a version that would satisfy their nostalgia, they could have downloaded AmosPro for free, downloaded an Amiga emulator for cheap, and rewritten using the Amiga chipset emulation in the emulator. I might someday write an AGA chipset version of the game just for kicks but I don't expect to make any money off of the Amiga version any more.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users












