22d772f08a
Flat sprites and collision bounds, controllable sprite ordering, and allowing sprite flipping without gravity flipping! Okay, so I'm silly. Red showed off some ACZ2 clips of the minecart and I was like "FUCK, THAT LOOKS TERRIBL- oh wait i drew that". But it wasn't the sprites that were bad, no - it was the fact that the sprites occupied a single position in 3d space and had pre-built-in-perspective, and THAT was terrible. So I basically over-engineered a solution instead. FF_PAPERSPRITE (name voted on by the public! http://i.imgur.com/i6g5P73.png) has: * Accurate perspective as if it were a linedef midtexture IN-MAP!!!!!!!!!!!!!!!!!!!!! might need a little bit of tweaking though, @RedEnchilada cough meow * As good ordering as you can get without seperating the sprite down the middle whenever it intersects something * Pretty dang accurate clipping - only exception is http://i.imgur.com/QNjbATB.png - where the MF_PAPER mobj has moved close to the wall and then turned, and you can't really solve that without cutting Sonic's feet off like in OGL <-- might be inaccurate, need to check with fixed ordering * I suck at understanding the casting to INT64 stuff that's used for overflow prevention elsewhere in the code, so I just cleaned up the most obvious and predictable overflow glitches manually. Still needs tweaking, though. * GFY one - the player rotating on the spot (recorded with the player having MF_PAPER): http://gfycat.com/WhichSpectacularDesertpupfish * GFY two - a ring box stays static as the player turns (recorded with the MF_PAPER check turned off): http://gfycat.com/SimpleShallowDeviltasmanian * GFY three - THE ACZ2 MINECART! What I MADE this for... http://gfycat.com/EsteemedPleasedDuck Also, MF_PAPERCOLLISION! * Collision bounds are limited to the surface of the MF_PAPERCOLLISION. These objects can kinda get stuck inside solid stuff when they turn, though - I tried to do some rudimentary pushing but it's glitchy as hell so it's put behind a #define for now, since stuck is generally better than overt glitching and can at least be user-mitigated. * To make space for this, MF_AMBUSH is now MF2_AMBUSH. Because it's more like an MF2 in all its uses, honestly. Literally no object definitions in info.c use that flag, and it's always applied at runtime - like all the other MF2s! Heck, there's some precedent - the mapthing flag MTF_OBJECTFLIP applies MF2_OBJECTFLIP. It just makes sense, and prevents wastage of our precious MF_ resources which are already dwindling so. Ultimately, I see several major uses of various combinations of these things: * Walls (for boxes/other shapes) with perspective that can cross sector boundaries at the expense of not being as thoroughly visually handled as polyobjects. * Flat, potentially moving hazards like Scrap Brain sawblades that are excessively simple to set up. * Robo-Hood's arrows and other types of elongated missiles being possible to dodge based on their apparent collision bounds rather than a solid cuboid. Nev3r is obviously of course already salivating thinking about what he can do with this. Unfortunately, the collision issues with regards to solid stuff will probably prevent people from giving MF_PAPERCOLLISION to everything (sorry, no Paper Mario Koopa Blast for now) since it's way too easy to get stuck at the moment. Hopefully that can be ironed out down the line - but if that makes you think this branch is incomplete, keep in mind that that this level of development was never actually my intent. In the end, I just wanted flat sprites to make my shitty minecart better, and I got that - the sawblade style stuff working accurately is just a further bonus! No relevant OpenGL code included because you know how I feel about that, but that should be easy enough for someone else to do at a later date considering the effect happens a lot in that renderer unintentionally. :V ALSO: I added another feature which (ab)uses some structural changes I made for papersprites. It's MF2_LINKDRAW! * Sets the sortscale of the mobj to that of its tracer. * Basically, Smiles' tails won't clip through shields thanks to this. * http://gfycat.com/GraveGlassEwe ALSO ALSO: I added ANOTHER feature. FF_VERTICALFLIP allows sprite flipping without gravity flipping. No need to bullet point, it stacks properly with gravity. http://gfycat.com/FrailLongKusimanse Test using <root>/toaster/flatminecart.wad (and <root>/!LatestSRB2Files/srb2win_branch_paper.exe if you can't compile!) MF2_LINKDRAW doesn't have a testwad but I'm doing a lot of Smiles stuff right now so it probably won't be too long. See merge request !37 |
||
|---|---|---|
| android | ||
| assets | ||
| bin | ||
| cmake/Modules | ||
| debian | ||
| doc | ||
| extras | ||
| libs | ||
| objs | ||
| src | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| Android.mk | ||
| CMakeLists.txt | ||
| Doxyfile | ||
| LICENSE | ||
| README.md | ||
| SRB2.cbp | ||
| SRB2_Debug.props | ||
| SRB2_Release.props | ||
| SRB2_common.props | ||
| Srb2.dev | ||
| appveyor.yml | ||
| comptime.bat | ||
| comptime.mk | ||
| comptime.props | ||
| comptime.sh | ||
| cpdebug.mk | ||
| srb2-vc9.sln | ||
| srb2-vc10.sln | ||
| srb2.png | ||
README.md
Sonic Robo Blast 2
Sonic Robo Blast 2 is a 3D Sonic the Hedgehog fangame based on a modified version of Doom Legacy.
Dependencies
- NASM (x86 builds only)
- SDL2 (Linux/OS X only)
- SDL2-Mixer (Linux/OS X only)
- libupnp (Linux/OS X only)
- libgme (Linux/OS X only)
Warning: 64-bit builds are not netgame compatible with 32-bit builds. Use at your own risk.
Compiling
See SRB2 Wiki/Source code compiling
Disclaimer
Sonic Team Junior is in no way affiliated with SEGA or Sonic Team. We do not claim ownership of any of SEGA's intellectual property used in SRB2.