Sonic and Sega Retro Message Board: MarkTheEchidna - Viewing Profile - Sonic and Sega Retro Message Board

Hey guys, I've been missing from this forum for some time. IRL stuff, basically. On September last year, I showcased a video of a 3D Sonic engine I was working with. (http://forums.sonicretro.org/index.php?sho...=0&p=504173)



Today, I'm releasing the source code for that engine under the MIT license.

What I didn't tell anyone back then was that the engine was written completely in javascript, and that it was running natively inside Google Chrome, thanks to WebGL! So, surprise! Everyone with a reasonably new video card should be able to run this on Windows, Linux or Mac OS X, without installing anything other than a browser. :-D

As the engine is nothing but a Web page, I thought WebSonic was an appropriate name.

"Live" Version:

http://achene.co/WebSonic/

Crossposting from github: (https://github.com/Coreh/WebSonic)



Grab the source here:

https://github.com/Coreh/WebSonic - Enjoy!

I was thinking that if we could get this to a more playable state, (with levels and enemies and whatnot) and if we could host it somewhere to whoever wanted to play, it would be mighty cool.

I recently found out that there are different/alternate algorithms for TCP congestion avoidance. For those who don't know what congestion avoidance is, it's a feature from TCP, (Transfer Control Protocol — A protocol used at the transport layer of the Internet) to dynamically adjust transmission speed to avoid network congestion, bandwidth waste and packet loss.

It seems that depending on the algorithm used for that, you can waste less bandwidth, or get higher transfer speeds.

I'm not sure if any of you have experience with this, but I'm going to ask anyway:

I'm configuring a Linux web server, and I would like to know: Have you guys tryied different congestion avoidance algorithms before? Which one is the best? I googled for information on that, but I couldn't find anything conclusive. Is it something like a trade-off? (Speed vs Bandwidth)

Reno seems to be particularly bad, and Linux uses CUBIC by default. Does that mean CUBIC is the fastest, or is it just the more balanced algorithm?

Thanks in advance.

Hello! Some of you might remember me as one of the creators of the BlitzSonic Engine. (Along with Damizean: He did like, 90% of it after the rewrite, so kudos for him :-) I've been really busy for the last 2 years or so with IRL stuff, mostly college and work, so I almost completely disappeared from the Interwebs. That is, until now.

ALERT: Giant wall of text ahead. If you're not much of a reading person, you can skip directly to the video at the bottom.

Partially motivated by my wish to put in practice what I've learned about linear algebra, computer graphics and game development in college, aswell by the recent Sonic 4 controversy and by a lot of personal reflection about what made the classic Sonic games so good (and why they're so different from what we have today) I decided to get back to fangaming.

What I'm going to show here is what I've been able to put together on my free time during the last 1 month or so. I was planning for a bigger, more 'surprise'-y release on a later date, but I decided that early feedback from the community was necessary to keep the project right on track. Besides that, I suck at keeping secrets :-).

I'm working on a "fully 3D" Sonic engine. That is, it's not an on-rails engine that tries to replicate the classics with 3D graphics, but an engine with completely 3d environments for you to explore and interact.

As I didn't want to stand on completely new grounds when it comes to the controls and physics, I decided to generalize the genesis physics for the 3D case. I've successfully implemented a pretty complete and consistent mathematical generalization of the physics described by Mercury on the physics guide (Thanks, man!). My goal is to have the game to handle exactly like Sonic 3 & Knuckles, considering you only touch the "left", "right", "crouch" and "jump" buttons, yet still allow for full blown 3D controls without switching control modes or whatnot. I'm already quite close to that, save for some minor floating point quirks with the air drag (which I'm not going to fix), and for the fact that collisions are checked using ray-triangle intersections, not height maps. (Also not going to fix.) You would be surprised on how well the physics of the original games stand on the third dimension.

Once the player code is ready, I'm going to release it for peer review, for whoever might be interested. If something's not like the classics (and it's not because of an explicit engineering decision) it's a bug that needs to be fixed.

Besides getting the game to handle properly, I'm using what I've learned from working on BlitzSonic to address the other important/unresolved issues with 3D Sonic games: Camera and Level Design.

For the level design, I'm keeping it faithful to the classics by using tile-based maps. The world is made of 3D, 128x128x128 tiles (each tile is a mesh). All objects are carefully constructed so they're exactly on the same scale as their Mega Drive-era counterparts, and the size of the player model in relation to the view size is also calibrated by adjusting the camera's field of view, to give the exact same feeling of speed as the Mega Drive games.

It might seem strange to use tiles for a 3D game, but they allow for great flexibility and consistency, and they're are going to make the creation of a level editor much easier.

For the camera, I'm addressing the problem by not addressing it at all: If you think about the cameras on the 3D Sonic games, you'll realize they were usually bad because they had to keep constantly changing their direction and position relative to the player. This is Ok on a slow-paced game, but not so Ok on a game like Sonic. The reason they had to do that, however, is because full blown 3D scenery usually occludes the player eventually (where 2D scenery usually doesn't.) If you address the occlusion problem, you don't need to address the camera problem anymore, and a static camera with some manual controls does the job quite well. This is what I'm doing; It is a similar approach to the one Team Ninja has taken on Metroid: Other-M, Thought their camera is certainly much more complex than that. (I haven't played it yet.)

Anyway, back to the engine, unlike most other 3D fan game projects, which are using either Blitz3D, Unity, Unreal or Build as a starting point, I'm working on a 100% custom 3D engine. I might get criticized for that, since it's an awful lot of work (it really is!) and software development these days is all about code reuse, but I decided to take the hard route for a variety of reasons:

1. I'm doing it for fun and learning, and I wanted to learn more about all the math and infrastuctural code that goes behind a full-fledged, modern 3D engine.

2. I did not want it to be based on proprietary technology, and I didn't quite like any of the free/open-source game engines out there. When you rely on proprietary technology, you're bound to be caught on technological roadblocks. Take Blitz3D, for example. The guys from BlitzResearch pretty much abandoned it. The result is that what once was a state-of-the-art 3d engine is now a piece of legacy code forever tied to DirectX 7.0 (which was released on 1999 and has no shader support) That means all the power of current GPUs can't be tapped, and that all the fancy effects can't be achieved (at least not easily/efficiently). All of the engine is based on open industry standards, which won't go away on a near future.

3. A Sonic the Hedgehog game is much more complicated than say, a first person shooter, (at least a simple one) and requires a lot of very specific architectural decisions. (take the collisions, for example) A pre-built solution wouldn't be able to provide that, or would require workarounds. "Generic"/All Purpose 3D engines usually try to be jack-of-all-trades, but end up being aces of none.

4. I'm a Mac user, and I am usually saddened by the lack of Mac support when it comes to (fan) games and game engines. I think the Linux folks should also agree with me. With a completely custom engine, I can address this, by making it cross platform.

5. With a custom 3D engine, I am only limited by what I can code on my free time. I don't have to pay for some extra component or wait until something is implemented for me. I can go and implement it myself, as I need it.

6. There's also another reason for me to code it from the ground up, which I'm going to reveal later. (It's worth the wait.)

Here's the engine's current feature set:

- Cross-platform, OpenGL based. Runs on Mac OS X, Linux and Windows out-of-the-box. Getting it to run on something else shouldn't be hard, provided the right libraries are available. A Direct3D backend for the ~60% or so of Windows users who don't have OpenGL drivers isn't entirely unlikely in the near future;
- Fully programmable, hardware accelerated scene rendering: Uses the full potential of GLSL Vertex and Fragment Shaders; (The FFP is bypassed entirely)
- Tile-Based 3D Environments;
- Objects;
- Spatial indexing using a dynamic, sparse grid structure implemented through hash tables (which have O(1) == constant access time) for super fast scene rendering and animation. Preeliminary tests have been done with 100,000+ objects randomly distributed along the scene space, without any performance hit;
- Asynchronous resource loading;
- Super fast ray-triangle intersections for collisions;
- Multiple render targets;
- Per-pixel (phong) lighting;
- Static (whole stage) and dynamic (local) shadow mapping;
- Automatic generation of static shadow maps during scene load; (Fast!)
- Post processing (glow effect, not enabled on the video)
- Adaptative framerate with support for "non-rendered substeps"; (To ensure playability even on computers with slow/low-end GPUs)
- 3D Sonic physics generalized from the Sega Genesis;
- "Ghost Mapping" to solve the occlusion problem;
- Ringloss;
- A 100% custom Sonic Model, made by taking the original game sprites as reference. Same proportions, same animations; (Not quite an engine feature)
- Blast Processing;
- Zero `Constant Execrations from Gimmicks like Booster`.

Besides that, the engine's code has been carefully profiled and optimized. All care has been taken to ensure great performance. (e.g. the engine tries to keep the same textures on the same GPU texture units whenever possible, to reduce the number of unnecessary flushes on the rendering pipeline).

Sorry for not providing anything playable at this time, but I only want to have public or even private beta tests for the engine when it's more complete. (And when some technical problems are solved)

The video below has a choppy framerate because my MacBook's low-end Intel GMA is struggling to deal with the game and the video capture program at the same time. Sorry about that too. Performance should be much better on good graphics hardware.

Enjoy!



@the admins: Thanks for such a speedy validation.