Discussion in 'General Sonic Discussion' started by Spinksy, Oct 21, 2014.
Transparency and distance Level fade out has been started.
Lots of respect to this person's dedication and drive.
Does X-treme's engine support rotating/shifting/modifying palettes?
If it does, do you generate an OpenGL texture and throw away the 8-bit PCX palette meta-data or do you keep it in memory in case the colors change, in order to generate a new texture for OpenGL?
Sounds like from the quote you might be generating once and throwing away?
It's unreal how all of this is happening so fast.
Right now I just put in the minimum amount of work to make the engine display textures, so for each texture I use its default palette and generate a single OpenGL texture with it.
I do not throw away the palette metadata, and I will support dynamically changing palettes, as the engine seems to be using them for a number of other effects too (besides simple palette animation), like lighting and fog, the engine precalculates multiple palettes to accomplish those effects.
I will generate some statistics on how often the palettes change, and for what reason, and based on that I will decide on what to do.
I will either pre-make different versions of the textures that correspond to the different palettes and store them all in memory (the textures are very small, so in the end it might not be too bad), or otherwise I will regenerate the textures on the fly when palettes change, it's a clear tradeoff of speed vs. memory.
Given that in a single frame a texture is used multiple times, potentially with different palettes, I might in the end create a hashmap that associates textures in a texture cache with hashes of each palette values so that I don't have to regenerate them all the time and I don't have to precalculate all palette combinations, we'll see...
Keep up the great work guys!!
I'm amazed they're making progress on getting it to run on Windows 8 so quickly. Jollyroger, you're doing a wonderful job.
Vote 1 for GEMPAL into official canon
That makes 2, One guy over on Senntient used him as an avatar already. lol
Does that count as "this shiat has gone Viral" yet ?
There is also yet another oddball discovery found within the game's entrapments.
Hold on while I find it ...
EDIT: Here we go,
This guys name is FRONT06.... he looks kind of bored....*Yawn*
Or, maybe he's yelling in frustration... (Xtreme can do that to people you know)
You know that's Calvin from Calvin and Hobbes, right?
The new Down Syndrome Sonic?
Sillyness aside, I am amazed by how fast the conversion to OpenGL has been going. How advanced is the v37 version of Ofer's engine? Does Sonic have the ability to do anything like this:
Or was it just a special effect like the spinslash thing? I'm hoping not, as this was one of the coolest things in that trailer.
v37 can do this, I have it working in the OpenGL version, I will send a screenshot to Andrew later tonight.
A shouting Calvin texture? Is that real?
When I learned OpenGL, fragment shaders weren't taught because nothing really supported them yet, but I think they'd probably be the perfect solution to the palette problem:
Unfortunately, I don't know if this is a viable suggestion because it's all or nothing. When you're using shaders you lose the standard way of binding and lighting textures because you need to build a shader just to display normal unmodified textures properly. As soon as you switch existing code to GLSL mode, everything goes completely black until you've specified shader logic for every texture. I wanted to update a mobile game I wrote several years ago to use shaders for some graphical effects and once I realized it wasn't straightforward I changed my mind. Just thought I'd bring it up though, because you'd have control of the texture colors in realtime. Maybe someone has already done something like this before and has a drop-in solution, not sure.
I guess the disadvantage is that anyone without a graphics card supporting GLSL would be SOL.
Edit: I guess this thought was mostly unnecessary. Just saw your post on assembler mentioning that you would probably use pixel shaders for perspective correction. I'm sure you have your reasons for not considering it here.
As promised! A screenshot of world rotations running in the Modern Windows port of the engine.
JR is also working on a first pass of the perspective correction, there are some issues but it's a start.
Yes its real, and no Calvin did not survive the night......... GEMPAL GOBELED HIM UP LIKE A CHICKEN NUGGET !
Any GPU that supports DirectX 9.0 and later can do fisheye and paletted textures through GLSL. I'm not convinced that palettes are necessary though, unless we are talking actual Saturn hardware with ~1MB of RAM.
A port of the game has no reason not to work on GeForce 8400, which is $10 on ebay. Yes I know what I'm talking about.
Not sure if anyone has thought to ask, but does the engine have programming for sound? I'm assuming by the fact that all videos kurisu ever shared had overdubbed music that the engine never even did sound effects, let alone music.
GLSL for fisheye is completely overkill, given that both the NV1 and the Saturn variants of the engine only use vertex transformations to achieve the effect.
Granted, the engine performs some smart subdivisions to compensate for the affine texture mapping issues, but obviously no fragment shaders are used.
Most definitely pretty old and very cheap cards easily support any features this engine will ever need.
Yes, fragment shader fisheye is an overkill, and produces a different result.
AXSX does a simple Vertex transformation in the vertex shader. Nobody is stopping you from doing those on the CPU as well.
The two engine versions we have (v37 and v40) use different camera projection code.
The older engine has no fisheye effect, and performs very simple vertex transformation to screen space.
The newer engine implements the fisheye effect directly in the vertex transformation code, jointly with perspective projection.
The newer engine is also considerably "leaner" in that several computations have been significantly reduced, and with them several features have been removed/downgraded; while the newer engine runs on both NV1 and Saturn, it is much more limited in functionality.
We have different options to proceed.
First of all I want to have both variants of the engine running on Windows, so that I can much more easily debug the code, which has lots of big and small issues, as it is clearly a work in progress.
Debugging directly on the Saturn is pretty close to torture given the state of the code.
That will give us a snapshot of the code we have, to preserve it and hopefully to release some relatively faithful binaries that represent as exactly as possible the code as was found.
After that we can work on both variants of the engine, for example re-porting parts of the old one to Saturn, or porting the fisheye effect to the old one, recreating the affine quad texture mapping faithfully, and whatever else we want to do to improve/change the code.
Separate names with a comma.