Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8515586 times) previous topic - next topic
0 Members and 82 Guests are viewing this topic.

Re: minisphere 1.4.1

Reply #675 –
Hm, looks like I'm going to have to leave the alpha blending code the way it is in 1.4.1.  It turns out Sphere 1.6 handles the BLEND mode like this:

Code: (cpp) [Select]
inline void blendRGBA(RGBA& dest, RGBA src)
{
    Blend3(dest, src, src.alpha);
    dest.alpha = 255;
}


Which appears to be impossible to do in hardware--or at least with the blend modes Allegro provides.  In most real-world cases the full RGBA blending works fine, for example the textboxes in Specs and... whatever the startup game does.

For what it's worth, the closest I could come to Sphere's actual behavior is this:
Code: (c) [Select]
al_set_separate_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA,
	ALLEGRO_ADD, ALLEGRO_ZERO, ALLEGRO_ONE);


This leaves the destination's alpha channel alone.  That fixed agrapher, but broke everything else; fully-transparent surfaces stay fully transparent regardless of what you render.  Not particularly useful.

Re: minisphere 1.4.1

Reply #676 –
Dont break spectacles! fixing the Alpha channel can be done in scripting as well (or maybe a new function). This will become useful for me once spritesets can be updated dynamically (to be able to swap clothes, armour and gear;and if those functions are not available, I can work around that by mixing to disk, and reload the spriteset).
Ill look better into a testcase for the crash on Windows (my platform is Linux now, so maybe it is a library, and not minisphere).

Slowly recovering my ranma demo. You see, long time ago I did remove all duplicate files from my backup, but then lost the original directories (svn) in a laptop crash. Thus, all I have now are spritesets and maps all over the place, without knowing which is newer and more complete.

Lord English, more stuff broke with the current version(Tue Jun 23 02:43:42 2015 -0400), see the attached print demo. All skewed canvas drawings are invisible (or are not being printed). The code is unreadable. I guess I was more focused on functionality at that time. (I guess that is the change that you wanted to roll back).
I also get a bit funky in puff-puff, where NPC's are able to grab powerups. A 9x9 layer is not stretched anymore and surfaces are not mirrored (the firedemo/sun). And in the highscores, the stylewindow is not filled in, something is printed, in very light blue, bot not inside it. Also, the skewing there is weird, the right-side of the logo is not wobbly as expected. I will break that down into smaller bugtests during the week. So do not worry... lots of genuine bugs to come!

There are successes also:
Kamatsu's pathfind.js runs out of the box, as well as my demo around that library (see picture).
I am modifying pathfind.js, as it uses strings as indexes, and numbers are (should be) faster. Will need to benchmark that.

Its fun to read your log. I saw also that stray printf, but thought nothing of it.
Tested the coffee script, but as I do not know it (bar that webpage that had some example code). It was fun to get it in.

mod sound is still a bit off for me.. the channels pan totally right/left, but I'm not sure if that is allegro or that it can be controlled in ms.

Re: minisphere 1.4.1

Reply #677 –
Don't know what you mean about the MOD sound, you'll have to explain that a bit more.

I just pushed a commit reverting to the original blending behavior.  Could you test again and see if that fixes the canvas stuff?
 

Re: minisphere 1.4.1

Reply #678 –
* print example is 100% ok again (better than 2 build back, as the integration symbol in the formula now displays fine, just as the extra wide plus sign, so something in the resize is now done right again)
* puffpuff highscores still not ok (and the colorbars are back to that because of the old transparency behavior). Image attached. Like I said, will make a simple test for that.
* The sound on Linux seems worse than on windows. But it is in the wine version of Sphere 1.7 too (1.6 with the ctypes working). so a mod is 4 channels: left,right,left,right and not slightly panned off center, as I remember making the music. So it is probably linux. I will have to edit the music in impulse tracker again, create an .it file, and test that. So ignore my comment for the moment, it is not minisphere. (audiere used to sound very good on windows... )

Re: minisphere 1.4.1

Reply #679 –
Hm, I wonder what's causing the window to be transparent like that.  As for the blending, the only way I can see to fully emulate Sphere 1.x would be to use a shader.  The fixed-function pipeline just isn't capable of it, and doing surfaces entirely in software is unfeasible as Allegro blitting performance for memory bitmaps is atrocious.

Re: minisphere 1.4.1

Reply #681 –
In theory I could use that, I don't see any combination of parameters which would emulate this however:

RGB = src * alpha + dest * (255 - alpha) / 255
A = 255

Re: minisphere 1.4.1

Reply #682 –
I'm 99% certain you can use the GL FFP to do this.

Quote from: Lord English – on

RGB = src * alpha + dest * (255 - alpha) / 255
A = 255


This would equate to RGB = SRC_RGB * SRC_ALPHA + DEST_RGB * (1 - DEST_ALPHA)?

Perhaps:
Code: (c) [Select]
glBlendColor(0.0f, 0.0f, 0.0f, 1.0f);
glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_DST_ALPHA, GL_CONSTANT_ALPHA, GL_ZERO);

Re: minisphere 1.4.1

Reply #683 –
Indeed, the tricky part is that Sphere does RGB blending using the source alpha, but explicitly sets the alpha of the destination to full opaque.  Kind of odd, but as you can see, a lot of existing code relies on it.

Edit: wait, I see it now.  Never mind me, I need to pay better attention. :)

Re: minisphere 1.4.1

Reply #684 –
Quote from: Flying Jester – on

Code: (c) [Select]
glBlendColor(0.0f, 0.0f, 0.0f, 1.0f);
glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_DST_ALPHA, GL_CONSTANT_ALPHA, GL_ZERO);



Hm, I did some reading, and glBlendFunc() actually sets the multiplier for the source and destination pixels, even with GL_CONSTANT_COLOR/ALPHA (so the "constant color" is actually a mask and is thus a misnomer).  So basically what your snippet does is overwrite the destination alpha channel with the one from the source image, the same as if you did this:
Code: [Select]
glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_DST_ALPHA, GL_ONE, GL_ZERO);


It doesn't unconditionally set the destination pixel to full opaque like Sphere does. :(  So yeah, I'm pretty sure I will have to use a shader.  No big deal, I already have the plumbing in place for shaders, it's easy enough to throw a few into the system folder for blending modes.

edit: That said, I did just send a pull request to implement constant-color blending in Allegro, since it's indeed a useful feature and I have no clue how it didn't make it in before now. :P

Re: minisphere 1.4.1

Reply #685 –
I just implemented engine-wide shader support in minisphere.  Previously shaders only applied to Galileo rendering, and a null shader (i.e. Allegro default) was used everywhere else.  Now minisphere looks for system.vs.glsl and system.fs.glsl in the system directory on startup and uses them if they are found.  These will be used to implement the Sphere 1.x blend and mask modes properly.

The engine will still work if the system shaders are unavailable, in which case it will fall back on the FFP (which will be inaccurate) and the aforementioned null shader.

edit: BAH!  It turns out you can't do blending in a shader because the fragment shader doesn't have access to the destination color, only the source fragment color.  Figures.

Re: minisphere 1.4.1

Reply #686 –
@FBnil
Good news, you found an unimplemented feature!  It seems I never implemented gradient windows...

I also got the blending closer to Sphere, but it's still not perfect.

edit: Got it!

Re: minisphere 1.4.1

Reply #687 –
;D yay! ;D

Re: minisphere 1.4.1

Reply #688 –
The only thing I can't figure out is why the fireball on the title isn't displaying.  I added a call to surface.save() to that part, and the image is empty, all black.  No sun.  Yet when I ran through the debugger the color values are right.  Apparently surface.setPixel() is broken.

The other bug I saw with this game is that the death animation isn't right, the car moves to a seemingly random location while it spins out.  I think MapToScreen() is glitched, but it works fine in Specs...

Re: minisphere 1.4.1

Reply #689 –
Okay, I fixed the fireball/sun thing, and also the mirroring.

I also figured out that MapToScreen() is bugged for small repeating layers due to aliasing (internally it just does a reverse mapping from ScreenToMap, if the layer repeats within a screen it's ambiguous where you are in relation to it).  I'm too tired to come up with a fix now though, I will work on it in the morning.  I'm also not sure why the enemy cars are picking up the power-ups...

edit: MapToScreen*() and ScreenToMap*() are now fixed.