Out of Pod Experience

Did you check my link?
I think it's what you actually want.

Regarding file formats ...

Png is quite good and 32bit.
PCX is RLE aka RunLength Encoding.

Aka [x amount of][Color]. This worked great with limited color sets and long lines of the same color,
completely unpractical nowadays.

Gifs are limited to 256 colors, which makes them a no go as well.


But with all that ... you still have to have all of them uncompressed in videoram anyway.
Of course you can use texture compression, but it won't save you much in the long run,
unless you go lossy... which sucks.

Actually, if you're using a sprite, you only need two or three angles: the user only sees one at any given time, and you can flip the existing sprite (in fact, that's why Link is ambidextrous in most sprite-based Legend of Zelda games; to save space on the cart, his sprite is simply flipped over to the required direction).

If you wanted to turn a sprite into a 3D image, the best option would just be to use a 3D model to begin with.

Somehow I missed it.

But that seems like a 3D rendering engine. Would it work well for high detail sprites? It looks to me like it's just the kind of thing that most 3D games use these days.

Thanks for the info on file formats. I don't really know much about em, but I guess good ol' .jpg and .png never fail to impress. And now .pcx makes a lot more sense!

So I have another question: would .jpg be able to save more space than .png with similar detail quality like it does in photos, or is there some sort of issue with it that would make it not work as well for this application?



That works great for cartooney low-detail sprites, but I'm talking about a level of realism that would require a completely unique set of sprites for the other side of the character. Even Wolfenstein 3D sprites rendered both sides of the character separately.

That forces the product to fail to have any improvements over the 3D model while causing the computer to perform excess processes. That will only give a rendering mask, nothing more. I'm looking for a whole new way to render objects in the first place, to allow enhanced level of detail and realism in some aspects with improved performance. You can't do that if you're still rendering a 3D-polygon object in the background.



But I think I have found something much better than a sprite engine, thanks to Sol pointing me in the right direction. There is a VERY old voxel-rendering engine called VOXLAP by Ken Silverman that was used in a few demonstrations for alternate ways to render 3D games. While this engine is old and severely lacking in the capabilities I envision, and its demonstrations like Voxelstein 3D are very low detail, I believe it sufficiently demonstrates that it is possible to render a 3D game in voxels without having severe memory implications. Modern computers should be able to render a much larger number of much smaller voxels along with added transparency and lighting effects to create photo-realistic 3D renderings.

I would approach the moving sprites differently than is done in Voxelstein 3D - whereas those are frozen shapes moving as 3D objects, I would make the sprite into a system of frames in which each one is captured separately against voxels that remain in place, making the character appear to move through frame rendering, with the individual voxels staying put on their grid.

I would also save further on rendering demands by rendering each voxel merely as a blip rather than as a semi-detailed cube with its own individual lighting effects. VOXLAP worked with much larger voxels that were easily visible to the player, but I'm talking about voxels the size of pixels on a high resolution setting.

I'm not talking about changing a voxel into any sort of image, only into a point which has a 3D position, color, transparency, and reflectiveness value. It is then merely a blip in the rendering program, and the trick to getting all of the blips to meet up against each other without having gaps is to make them render at the right size.



That Euclideon engine is very close to what I had in mind! There's just one thing missing from it: translucent and transparent object rendering. Without going into extremes such as secondary and tertiary realtime ray tracing or refractive effects, simple clouds, windows, and mirrors can be made to look almost completely photorealistic in real-time rendering if these objects are made with transparency and reflectiveness values. Each voxel then has its blip color determined by a set of processes:

1.) the voxel base color is calculated against the brightness of light upon it
2.) the reflectiveness value causes a portion of the voxel color to be swapped with the color light reflected upon it
3.) the transparency value determines how well voxels behind it can be seen as well as how well light gets through to the voxels behind

It's a blip. That means it's a point of light. As you get closer, it just gets bigger but still has no discernible features. By describing it as having a size of about a pixel, I mean that its size will be similar to the pixels on the textures on a modern 3D model in a game. Point is, small enough that you don't usually notice it by itself unless you get up close.

If you do get close, it's still just a blip, but it takes up more pixels on your screen. There is no shape to it, only a center and an edge which extends to a given distance which causes it to meet the other voxels near it. I imagine it in my head as a circle but it probably makes more sense by the way our computers access data to display it as a square. Also a square mostly helps make the voxels successfully overlap each other slightly without leaving gaps and without overlapping so far as to disrupt the image quality at somewhat small distances.

Here's a demonstration of how it works: Euclideon Makes World's Most Realistic Graphics

An explanation of point clouds: Point Cloud - Wikipedia
We can already make point clouds. If we take a step further and use some first-level ray-tracing, we can determine which points should be concealed from view because there are points in front of them, then further can determine which points should have how much light applied to them.



Oh I guess the list of traits of the voxel I'm picturing is a bit longer than I previously mentioned:
1.) reflective red value
2.) reflective green value
3.) reflective blue value
4.) fluorescent red value
5.) fluorescent green value
6.) fluorescent blue value
7.) transparency
8.) shininess
9.) strength of red ambient light
10.) strength of green ambient light
11.) strength of blue ambient light
And the rest is done through ray-tracing. Each trait can be stored in 8 bits (0-255) and that makes a voxel have a maximum data size of 88 bits. This contrasts with 32-bit images in that the maximum data size per pixel is 32 bits. But with the use of special algorithms, the data cost for rendering these voxels can be greatly reduced, much like how we reduce the cost of rendering images through the use of special algorithms.

I have a lot of difficulty learning programming languages. They don't interest me much. I like to speculate about possibilities and I really do have a pretty reasonable understanding of how data storage and data access works and what limitations it has, but there is always a certain amount of it that eludes me.