PS Vita port?

[0lorak]

This is a comment more than an issue.
I know that there is a way to play this game in PSP -thanks to Andrew Church-.
This game would play better than the PSP port if we can play it natively on the PS Vita. Now with the Switch port already released maybe someone would do it for the PS Vita.

[fgenesis]

Oh, that's new! I wasn't aware someone did a switch port, that's cool. I'd love to make this semi-official and merge the changes as i plan to continue hacking on Aquaria (and the sequel mod) once real life(TM) is less of a burden. Having the switch version and any other platform evolve in tandem would be great. There's so much to do and supporting more platforms would make the code as a whole better. One fork per platform isn't preferrable in the long term, imo.

Unfortunately i don't own a vita or a switch so i can't help with that, sorry. But i can confirm that it works on windows 98 + KernelEx if anyone cares about that. :)

@dimag0g (does this notification thing even work?), what about your switch port becomes its own branch under AquariaOSE until it can go into master? Got some other half-finished things in the pipeline i'd like to land once i have more time.

Also: If anyone reading this wants to discuss platform and ports, we're on IRC (#bitblot on esper.net) and there's also a discord linked somewhere on the steam forums that's crosslinked to that IRC.
EDIT: there

[dimag0g]

@fgenesis Yeah, that notification worked! I'm totally cool if my stuff goes to the original repo. I'm by no means a git expert, so my repo is a bit of a mess right now, that's why I didn't offer any pull requests yet. I'll try to keep crossplatform changes in master and switch-related stuff in switch. Note that current switch changes are mostly dirty hacks breaking the code on other platforms, I'm not into polishing yet.

Give me time (a month? more?) and I'll eventually ping you with pull requests. If you're about to push more changes to the main repo, I'll merge. Or, if you think we should have a switch branch in the main repo right away, tell me what I should do.

AFAIK PSP port features significant changes meant to fit the game into 32MB of RAM, which are unlikely to be useful for future ports. PS Vita port would have been easier to do, but I'm not sure how likely is that to happen now that Vita is EoL.

[fgenesis]

I'll try to keep crossplatform changes in master and switch-related stuff in switch.

Good. Btw, thank you for doing this.

Note that current switch changes are mostly dirty hacks breaking the code on other platforms, I'm not into polishing yet.

That was the same for that MorphOS fork back then, I didn't merge that because it basically broke everything else (including renaming lots of OS and library calls for no reason? come on).

Give me time (a month? more?) and I'll eventually ping you with pull requests.

That would be great, take your time.

If you're about to push more changes to the main repo, I'll merge. Or, if you think we should have a switch branch in the main repo right away, tell me what I should do.

Not anytime soon. I want to, but just not enough time/brain. But I suggest you rebase against experimental eventually, that one is where dev happens (master is the stable branch that only gets compile fixes). I haven't touched that one in a while either; did a lot of changes in controllerfixup which is still a dirty WIP, and later I noticed it didn't go anywhere so i branched off controllerfuckup, which tests a few things and is even worse. But this is my mess and shouldn't impact you in any way; i'll sift through that eventually. See issue #28.

I have to admit i also didn't use git very cleanly and did a lot of unrelated changes in controllerfixup since there was opportunity after some changes in the code there, so i think the code is in a state of perpetual horrible mess either way. So no prob if yours is also mess. It'll work out.

One question regarding inputs and controllers: How much did you have to touch the input handling code? That's what those branches i mentioned do; refactor that into something more workable. If SDL2 supports the switch out of the box it'll be fine, but if it needs bigger changes please let me know so i can adapt to your changes (which are probably better than my controllerfuckup mess...)

AFAIK PSP port features significant changes meant to fit the game into 32MB of RAM, which are unlikely to be useful for future ports.

Some of them. Less RAM is always good. Shrinking the max. map size, not so much. I have some things planned for texture compression and overdraw/alpha-blending reduction similar to what achurch did but it's on ice for now.

PS Vita port would have been easier to do, but I'm not sure how likely is that to happen now that Vita is EoL.

I'd be glad if someone does it. If i had a vita and some time i'd give it a shot, but doesn't look like it for now.

Wii is also EOL and there is no Wii port yet and there totally should be one. I do own a Wii but i didn't look into developing for the thing yet. Gamecube has 24 MB RAM so there's another challenge if the PSP's 32 MB is still enough RAM :)

One of the bigger long-term plans is to rip the rendering code out of the engine and move that to its own backend; OpenGL 1.1 is dated and at least there should be a GLES backend. I've done something similar at work and such a separation would benefit all platforms; multiple backends:

• Wii has its own thing (gx or whatever it was called)
• GLES for all those crappy handheld devices
• GL3/4 for PC
• Maybe vulkan? Haven't done that yet and it would be a good learning experience.
• nobody wants DirectX

But this is something that requires careful planning since the GL calls are so deeply entangled with the rest of the code D:

[dimag0g]

@fgenesis
Right now there is literally zero changes to the input code. There should be some changes eventually: Switch detects both joy-cons as a single joystick in handheld mode (when joy-cons are attached), but in docked mode left and right joy-cons become joysticks 1 and 2. I didn't touch that stuff yet. Right now I'm still busy covering graphical glitches with duct tape.

Regarding graphical backends, GLES makes little sense as a target IMO. There is an OpenGL emulation using GLES if you're stuck with hardware which has nothing else (https://github.com/ptitSeb/gl4es), and on newer devices like Switch there's OpenGL via EGL.

[0lorak]

Here is the note about Aquaria PSP port. There is also a Youtube link.
More info in this link.

[isage]

Vita port is possible, now that we have access to scePiglet (official gles2->gxm library) and support for it in SDL2, but would require GLES2-compatible render in Aquaria (i wonder how switch port even works, i thought switch also was gles2-only?).
Moreover, it would require rewriting all shaders from glsl to Cg (but that's fairly easy task).
I did some initial tinkering, and right now it compiles, but fails to link, obviously, due to missing immediate gl functions

[0lorak]

@isage: Great to hear it!

[fgenesis]

Vita port is possible, now that we have access to scePiglet (official gles2->gxm library) and support for it in SDL2, but would require GLES2-compatible render in Aquaria (i wonder how switch port even works, i thought switch also was gles2-only?).
Moreover, it would require rewriting all shaders from glsl to Cg (but that's fairly easy task).

Vanilla Aquaria has no shaders. The backend was unfinished and i eventually fixed and enabled it, so mods can use shaders, but that would be problematic for porting, correct? I suppose the most portable options is no frame buffer effects + no shaders, but ofc it's also the least fancy...

I did some initial tinkering, and right now it compiles, but fails to link, obviously, due to missing immediate gl functions

What about a plain SDL2 backend as fallback? Something to consider for a future renderer separation.

Since Aquaria is mostly just rotated and stretched 2D sprites that should be possible (again, no FB, no fancy). I'm not sure about certain bone deformation effects (bone strips mode), that is a sprite but rendered with custom vertex positions. Does SDL2 have an API for that?

EDIT: Plant movement (wobbly idle or swishing when passing by) is another case that uses custom vertex positions.

Anything else i'm overlooking?

[isage]

Oh, right, i forgot that aquaria has no shaders, just script api to load them. I think in modern world shaders and framebuffer effects are fairly portable (hell, even sdl2 has texture rendertarget). Shaders are not problematic, but it would be nice to have shader selection based on target platform/api (e.g. modmaker makes separate versions of shader for different target, engine loads correct one)

About plain SDL2 - sadly, it only supports rectangular textures

[fgenesis]

Shaders are... annoying, actually. If everything supported proper GLSL that would be easy, but then again each driver does its own thing, and has its own bugs, and it's own interpretation of certain things... i've done this a lot in the last 4 years, not for Aquaria, but i've learned to hate shader compilers. Then there's Spir-V, which avoids that problem but is not supported on older hardware, and spir-V is (iirc) incompatible to old GLSL, unless someone made a glslang translation backend in the meantime that actually works.

modmaker makes separate versions of shader for different target

For mod authors that's too much of a burden, i think. Next we'll end up having to implement the same shaders in old GLSL (simple uniforms), new GLSL (UBOs only), HLSL (for DirectX), CG (for... both and vita?), and Spir-V (good tools for translation from/to), for good measure. Please no. It would be ok if this can be automated with a tool or script, based on glslang or something...

About plain SDL2 - sadly, it only supports rectangular textures

Then this is out, for now. I had an imgui-style rendering backend in mind. Simple, easy to port to $platform, separate from the game logic. But this is for another day after planning carefully. gxm was the vita chip/api? Ideally this could be used directly if the aquaria-side render api is simple enough.

If you look at the layer drawing logic you'll know what i mean, once i accidentally added a bug and only noticed it months later because it broke the hug (one arm of Naija/Li was drawn in the wrong z-order). The layer code is a complete mess. There are about 72 layers, which can be freely reordered, then some layers can have multi-pass (search for "layerpass" in the code), and there's more.

Some pointers, on top of my head without checking much code, it's been a while since i've rummaged around in that part of the code:

• Lua setOverrideRenderPass() vs setRenderPass() (except that entity_setRenderPass() is actually entity_setOverrideRenderPass, see entity_setRenderPass_override). That was what broke the hug, i forgot that special case. But i never really figured out the difference between override and non-override pass...

• DSQ::resetLayerPasses(). Layer passes, [-2 .. 5] by default, but only for some layers. Can be adjusted via Lua setLayerRenderPass() per-layer. Seems quite costly to have this enabled. The code goes over a layer multiple times and draws specific objects each time (where pass matches the value set via setRenderPass() ). Kinda like a secondary ordering within a layer.

• Core.h, vector<> renderObjectLayerOrder. Another indirection, but only set during init and not changed afterwards.

• Lua entity_setEntityLayer() uses a different indexing scheme but actually maps to the normal game layers. Presumably to make mod authors life easier. Back in the day this was the only function that could move an entity to another layer (but only a fixed set) after it was created; I added some others (*_setLayer()) later.

I'd like to move all of this weird crap away so that all that the game renderer does is to create draw lists (can even multithread object collection per-layer) and those are then fed into the actual gfx renderer, no more logic involved there.

[isage]

GXM is vita api. It's somewhat similar to opengl (although uses absolutely different way of initialisation, and requires begin/end on each frame) and supports only non-fixed pipeline (so shaders are required anyway, but could be built in the render)

…

[isage]

SDL2 now has SDL_RenderGeometry, so deformations are now possible. So, except for shaders, rendering can be implemented completely via SDL

[leonvdo]

hey would aquaria vista version be updated any longer? best wishes from another side of the earth, lol uh actually im asking for my friend but it doesnt hurt the spirit ;)

[0lorak]

I forgot about this. Are there any news?

[fgenesis]

hey would aquaria vista version be updated any longer? best wishes from another side of the earth, lol uh actually im asking for my friend but it doesnt hurt the spirit ;)

Sorry, never noticed this question.
I'm trying to keep down to win98+kernelEx compatibility. XP definitely. Hope that answers it ;)

I forgot about this. Are there any news?

Maybe? A little? I'm in the middle of reworking the renderer to use VBOs if the hardware supports it, and get OpenGL calls out of the rest of the engine in a followup step.
I'd like to get the renderer to a point where all it needs to do is consume lists of (vbo, texture, matrix, color) entries prepared by the game. It's still a long road to get there though.

[0lorak]

Good news!!
Any progress for an hypothetical Aquaria PS Vita port?