Discussion in 'Fangaming Discussion' started by Lanzer, Jun 24, 2014.
Here's the concept art I made for CPZ. Figure someone might find it interesting!
I tried the demo today. Doesn't work in WINE or VMWare so I had to boot into Windows. (Note to developers: Don't bother trying to roll a Mac build right now. You're using OpenTK and there's an unresolved type binding issue between the Xamarin linker and OpenTK which prevents anything from running unless you target the deprecated MonoMac libraries instead, but that would require users to install the Mono runtimes. It's one of the same problems that is currently halting development on the macOS port of BizHawk 2.0 and I've got a ticket open for a related issue with Microsoft which they keep punting the fix down the line to later releases.)
Anyway, the game is interesting. Emerald Hill seems slightly out of place compared to how amazing Chemical Plant and Hill top look. In full screen mode it seems like VSync is disabled - I was getting lots of screen tearing and framerate drops. But switching to windowed mode, even if the window was maximized, had no Vsync issues and no framerate drop issues that full screen was having. There are some situations where the physics are slightly off, like if you take the secret route in chemical plant 2 the force of hitting one of the 3 monitors at the end of the loop is enough to send you back up the loop, which didn't happen in the original.
Overall I didn't really care for the stills and initial videos and thought the original art was still better, but after playing Chemical Plant and Hill Top I've changed my mind and I think the art style fits the game just fine.
We aren't using the Xamarin fork, but the original OpenTK one. I do plan on porting it to OS X in the near future. OpenTK does run on OS X normally, though I don't know if that covers OS X 10.10 and higher, have only tried it with earlier versions.
So you are experienced with .Net/mono on Mac? I might need to ask you in the future some questions on how to package a .dmg file or otherwise distribute it so that the user doesnt have to manually download mono and write in the console.
I don't have anything against Sonic 2 HD or anyone related to it, and I gonna say that it looks and plays FANTASTICALLY, so I hope that this game gets supported, a lot of luck and progress...
...but not being able to play the SAGE 2017 demo because of that it needs OpenGL 3.3 sucks a lot for me, specially when I can't upgrade my laptop hardware (because of where I live, but that is another story). I guess that of course it MAY sound rather useless or unecessary, but could it be possible that OpenGL 3.1 (apparently what my intel pentium b960 supports in windows) is supported in the game?
No, I'm specifically referring to the official OpenTK library. The Xamarin fork is old and crusty.
Xamarin.Mac is what you need to use to package it so the user doesn't have to download Mono, and it doesn't work. The reason Xamarin.Mac fails is because it has a linker that looks for .NET dependencies and just bundles them into the compiled executable so the user doesn't need Mono, but that gets confused by OpenTK because of all of the stuff that it supports and either 1 of 2 things happen depending on build settings:
1. The build fails because it tries to link to both OpenGL and OpenGL ES (mobile) libraries and fails because there is no OpenGL ES to link against on a desktop.
2. The build completes without error but fails at runtime because the OpenTK stuff got optimized away because it thought it wasn't being used.
OpenTK 1.1 works, but there were some API changes between 1.1 and 2.0 (thus 3.0 as well) which makes it not really a good work-around. Anyway, to answer your other question, yes, I've been doing .NET stuff on Mac since around 2012. If you've got any questions I could probably answer them, but right now I think you're blocked by the OpenTK problem if you want a build that doesn't require Mono. On the plus side, if you don't want to use Xamarin.Mac, the legacy MonoMac stuff will detect if Mono is missing on launch and take the user to the download page for it. I'm sure the OpenTK issue will get resolved though, if someone else doesn't figure it out soon I'm going to start ripping stuff out until I figure out what's making it fail.
So you guys are on track to do what you're setting out to do. Props. I want Sonic 2 HD to be the best it can be, so I naturally I have some suggestions.
I would look at overall consistency in the art direction for the background art. Sometimes redesigned tiles look very different, and sometimes they look like you couldn't think of anything so you upscaled the original art, more or less. Both approaches have merit, considering the goals of this project, but if it looks inconsistent overall, you're doing yourselves a disservice.
I also think you should reevaluate how you're styling game actors. Sometimes the player or enemies kinda just blend into the scenery, cause it's all styled the same way for the most part. If I may go further, I think game actors should be done in one of two ways. They should either be cel-shaded, or they should be 3D models. Both approaches would help game actors stand out against the scenery a lot more, although you'll have an easier time adding and tweaking existing animations with the former approach.
The game engine itself is very close to the real deal, and I'm not sure just how much closer it can really get. There is some unexpected behaviour when trying to utilize small dips and hills in the terrain, and incorrect behaviour when launching off of certain quarterpipes (incorrect, or at least inconsistent with the source material). Both of these problems are most noticeable in Hill Top Zone, but occur throughout the demo.
Finally, there is an issue where sometimes the player character will land, and the sprite will visibly rotate to match the actual angle. It looks tacky. It's the only thing in this demo that I'd outright describe as "looking like some Flash game from 2007".
@winterhell Would you consider providing the option for the engine to use wider aspect ratios than 16:9 (like 21:9)? I'm not sure how much enemy behavior relies on the screen bounds in Sonic 2, but I guess the biggest problem would be bosses*. I realize 2D genres are the hardest to get to work properly with variable aspect ratios, but when it works, it works so good. I understand if such an option never makes it in for game design reasons.
*: An elegant & cheap solution could be to just add a stylized border on these fights.
Hey WinterHell, there's a glitch in Hill Top Zone act 2 when the lava rises where, occasionally, an errant level chunk will appear floating over the playing field for a few seconds. This leads me to wondering what exactly the bottleneck for your performance is. Without being too presumptuous, what is the dimensions of the smallest rendering shape you are using? I.E. could you please describe your Vertex Array Object definitions? The reason I ask is because, if your smallest drawing VAO is a single chunk, that's sort of an inefficient way to handle things. You should use batching so that the entire screen's background is a single VAO, and thus a single draw call. You can do similar with sprites -- are each sprite/object a separate draw call? What I do is I have a batch of redundant quads in a VAO, like 40-80, which all draw in a single call, with each one being the equivalent of a hardware sprite on the genesis. If I need to draw more than, say, 80 sprites on screen at once, I can do it using plexing just like a real console. I use a streaming texture to give my shaders which handles the drawing of these VAOs the correct information they need. I.e. I have a texture glyph that is basically the SST. If, for example, I'm only drawing 20 objects on screen at once, and my drawing VAO batch for sprites is 40 big, then I just discard the remaining 20 in the fragment shader.
Sorry if this is way off from what is actually bottlenecking your performance, just some brain storming on my part.
It's low-ish end integrated graphics from 2009 - I don't expect good performance
Might be worth doing some benchmarks on how you render Sonic and Tails though - if I'm reading this properly and you've basically got a massive texture in memory that you clip bits out of at runtime, that might not actually be faster than having 34924803294 individual textures in memory for each frame. I suspect the rules are different for low resolution, low colour graphics than they are for HD assets.
Either way I suspect graphics performance is the bottleneck for everyone experiencing problems.
It is almost assuredly not faster to work this way - there is a performance hit in openGL when one binds textures to a texture unit for shaders to access them, and it's always a good idea to limit the number of bound textures in any program -- ideally, you want to keep the number of required texture units below 16 to maximize compatibility. There are already people complaining that this requires OpenGL 3, which is 9 years old. Imagine if the game required like 512 texture units, lol.
One giant texture glyph is usually the way to go, the trick would be to figure out how to reduce the size of the glyph. That's why i suggested perhaps looking into tiling. It doesn't even have to be square tiles, just good enough to reduce the texture size. I.e. how many different, unique Sonic heads are there in the texture, that are reused in many animations? If the number of unique Sonic heads are small enough, one could split Sonic's sprites into two - one for the head, one for the body, to reduce the texture size, then recombine them in the fragment shader using UV fuckery.
@Dario yeah we'll fix that in the coming patch to have correct letterboxing and pillarboxing.
Sonic and Tails do take a lot of Video memory, so its worth considering streaming them from the system ram.
The next demo is going to run on OpenGL 1.3 or 2.0 (basically any OpenGL card with GLSL 1.1 shaders, like GeForce 3 Ti)
We are not bounding more than 4 textures at once.
So I assume that's a no on regards to increasing the visible game play area?
Actually I just remembered that Sky Chase would also be a troublesome stage to give an increased area and would need to be restricted as well to the new 16:9 ratio.
I would definitely support OpenGL 2.(1) over OpenGL 1.3, if only because you'll find GLSL support with 1.3 wonky on wider hardware. It was OpenGL 2.0 that moved GLSL into the core profile. 2.1 is better to support than 2.0, though, because it rolled in some changes that increased 1.3 hardware support.
For now we are with a fixed 16:9 image.
Increasing the visual area might break some bosses and would require rework on the title screen and the special stages for example.
There is a possibility some play modes in the future to allow seeing more of the terrain at once, but it doesnt seem right for the regular play.
@CoolJerk people would be free to try running the game with GeForce 2 or 4 MX, it simply would fail on the shader compile stage.
Hm, so what's you're solution to that? Or are you planning on going back to pre-C-style GLSL?
If you are talking about assembly- not at all. With GLSL 1.1 you can do anything we are doing right now. I've made tests with #version 110 on GeForce 6200, also on OpenGL ES 2.0 .
The biggest thing we are 'missing' from OpenGL 3.3 is really the VAOs.
Ah, thats great to hear that you've already got tests running. Myself, I can't go back to the time before VAOs, I find them a godsend haha. Best of luck!
One little nitpick - holding duck while Robotnik drops the Mega Mack on you in CPZ's boss no longer protects you.
wow subtweeting taxman I see
I have a friend who apparently can't play the game because specs and it won't reduce from 1080p resolution? Dunno how accurate this is but maybe worth looking into. If you need the specs let me know.
Separate names with a comma.