nix: update to emscripten 3.1.64
Remove use of legacy GL_PERSPECTIVE_CORRECTION_HINT
Disable intro plugscreens for emscripten builds for now
Use stored background color instead of glGetFloatv() call that is slow in emscripten due to wasm<>javascript context switch
Co-authored-by: Thibault Lemaire <thibault.lemaire@protonmail.com>
This commit fixes the issue when ship guns remain in the position (angle and declination) of the latest shot - now guns slowly rotate to the initial position after battle.
Guns reset can be initiated simultaneously with ship alignment, but intentionally done sequentially - we align the ship, don't see any other target and only then turn guns back.
Make it a bit more explicit that we're ignoring some(many) warnings
`-w` ignored *all* warnings. Which is 1) not very sane and 2) easy to miss
`-Werror` will
1. ensure we don't add new categories of bugs in new code/refactors (some of the changes here are evidence that I, for one, leaned too much on "no compile error? No problem")
2. allow us to fix those warnings step by step
Some warnings are not attached to a category and thus cannot be disabled individually. Using `-Werror` turned those into errors, which forced me to fix them.
Note: Not tested with clang
Co-authored-by: Rafael Brune <mail@rbrune.de>
Fix windows redefine errors
Fix strict aliasing errors by using copies instead of casts
SDL keycodes correspond to the character that should be generated when
a key is pressed. It is unnecessary to convert this into a readable
key name to determine which key has been pressed. More than this, in
some cases it is incorrect -- the readable name for the space key, for
example, is "Space", and using the first character of this string to
determine what character to insert results in an 's', not a space!
This error would also cause function keys to insert an 'f', rather
than being ignored.
This commit also ignores any characters whose byte representation lies
outside the range from 0 to KEY_TOAL_KEYS, as we do not have a
character mapping for such keys.
Fixes#63.
These changes restore the original rgl vertex shading code. Instead of relying on opengl material and lighting code to generate vertex colors the internal CPU code path is used to calculate the vertex colors. This restores the original brightness of the shadowed side of meshes and the specular highlight on the nebulae. Probably also other things.
This has the unfortunate side effect of removing someone's previous attempt of modernizing the render path using VBOs (vertex buffers on the GPU). When we get to implement a completely alternate modern opengl render path that reimplements the CPU side vertex shading as GPU vertex and pixel shader we will return to gpu buffers but for the sake of correctness they have to go for now.
The logic for swapping these defines around is the following:
- We want the most stable code in release builds, so it's okay to sacrifice (theoretical) speed
- We want to catch logic errors in debug builds
The meshMorphedObjectRender() takes two frames of an animation (based on different meshes and textures) interpolates between them and renders them. This requires a certain set of requirements to be met such as the two meshes having the same amount of vertices+polygons and the vertex indices of the polygons matching. The code also mandates that the UV coordinates at the vertices match and leverages that by just using the UV coordinates of the base mesh (first frame of animation).
Turns out the ion beam (bulletionray.ebg) has 4 frames defined:
```
label(beamMesh)
morphAnimDWORD(ETG\meshes\misc\beamRibbon.geo, 0)
morphAnimDWORD(ETG\meshes\misc\beamRibbon01.geo, 1)
morphAnimDWORD(ETG\meshes\misc\beamRibbon01.geo, 0)
morphAnimDWORD(ETG\meshes\misc\beamRibbon01.geo, 2)
```
The 0,1,2 at the end define flags. 2 meaning the end of a loop, 1 beginning of a loop. Effectively the animation only iterates through frames 1,2,3 and never uses frame 0. The ebg file also sets the start frame to 1 skipping 0 completely. But frame 0 is still loaded as the base mesh.
Now it turns out that beamRibbon.geo and beamRibbon01.geo do not have matching UVs - and since the rendering code relies on the UVs of the base mesh we have the weird rendering of tip of the ion beam were the UVs diverge. It looks like the ion beam animation was changed at one point to start at frame 1, probably because it looked very weird with the tip of the beam flickering due to the UV mismatch.
Now one could either fix this by correcting the content. Either through modified .ebg files (there are multiple beams with the same issue). By editing the geometry files to match the UVs - or by making the mesh morph rendering code use the actual UVs from the animated meshes and not use the static base mesh just for them.
This is what this MR does: UVs are now interpolated between animation frames in the same way as vertices and normals are. This fixes the rendering and makes the system a little bit more correct and powerful.
In principle this should not cause any new issues (hopefully there are no completely broken particle meshes).
