[test-object]

So, seeing as the first steps towards the Special Stage just arrived, how about we change the emerald ending a little?
It was always kind of dumb as when you finished the half-pipe but with too few rings, the emerald just floated above your head without Sonic grabbing it. Maybe it can fly away... or hell, we can even let Sonic grab it if you DO have enough rings.

[Canned Karma]

Progress Report - 6/19/10

I'm not going to do a complete breakdown like I did last time because I really don't see a need for it now. There has been much more activity recently in the level art, thanks in no small part to MaximusDM's efforts and Test-Object coming back into the picture. These are just two of the people who have stepped up, and I'd like to thank everyone who has put their effort in over the past month. By all means keep at it.

Special kudos go to Synergy. He has single handedly created a working test build of the Special Stage and far surpassed our initial expectations. Job incredibly well done there, and things are just getting started in that area.

Character art, badniks and music are essentially in the same place they were at the last update. For the time being I am removing music as one of the goals. We have a contributor who wishes to remain anonymous at the current time who has submitted an amazing HTZ remaster and wants to refine it even more before it is made public.

So where does the project go from here? The same place it was before, but we're going to turn things up a notch in asset production. The community has been struggling to get things done for art, so the staff is now going to step in, and with full transparency start creating the same assets we put up as goals over three months ago. This means you guys are going to see the steps Gambit goes through with level art, Cerulean Nights' workflow for badnik creation (and if you're interested in making them and still haven't looked at the great tutorial he created then what the hell is wrong with you), and the method Vincent uses for his character designs in doing the small animals. At this point, everyone on staff wants to put Hill Top Zone into the alpha, and by showing everyone here the step by step methods we've been using I hope more of you who have been lurking will come out and post up your thoughts as well. Many of you have wanted to see our works in progress, and starting next week you will. More specifically, Gambit will be starting on the S tunnel metablock for level art, and Cerulean Nights will be doing the Spiker.

Andlabs brought up a good question about the code side of things. Here's what LOst has been utilizing so far:

Code system:
C++ object oriented optimized with disassembling and debugging.

Tools:
Microsoft Visual C++ 2008 x32 and x64.

Libraries:
Direct3D 9
DirectInput 8
DirectSound 8
OpenGL 2.0 with frame buffer extension (became standard in 3.0)

Hopefully that information is useful to those of you with programming backgrounds that have been wondering if you'd have a way to contribute. Let me reiterate that as of this point, we are still in need of someone who can help us get the multiplayer segment of S2HD up and running. Right now we have ideas that we've been tossing around for it, but no actual work has been done on that front. If you have ideas, please send me a PM if it's something specific or just post up general ideas in this thread. For detailed questions I'll have to get feedback from LOst to give you definitive answers, but I'll definitely see what we can do to make things as simple for you guys as is possible on our end.

[zemulii]

So, seeing as the first steps towards the Special Stage just arrived, how about we change the emerald ending a little?
It was always kind of dumb as when you finished the half-pipe but with too few rings, the emerald just floated above your head without Sonic grabbing it. Maybe it can fly away... or hell, we can even let Sonic grab it if you DO have enough rings.

I'd love to be able to jump up and collect it or something.

The community has been struggling to get things done for art, so the staff is now going to step in, and with full transparency start creating the same assets we put up as goals over three months ago. This means you guys are going to see the steps Gambit goes through with level art, Cerulean Nights' workflow for badnik creation (and if you're interested in making them and still haven't looked at the great tutorial he created then what the hell is wrong with you), and the method Vincent uses for his character designs in doing the small animals.

GREAT news! I hope it has the effect it should. It's always interesting and helpful to follow along and see how others get from one point to another.

[Conan Kudo]

Andlabs brought up a good question about the code side of things. Here's what LOst has been utilizing so far:

Code system:
C++ object oriented optimized with disassembling and debugging.

Tools:
Microsoft Visual C++ 2008 x32 and x64.

Libraries:
Direct3D 9
DirectInput 8
DirectSound 8
OpenGL 2.0 with frame buffer extension (became standard in 3.0)

Hopefully that information is useful to those of you with programming backgrounds that have been wondering if you'd have a way to contribute. Let me reiterate that as of this point, we are still in need of someone who can help us get the multiplayer segment of S2HD up and running. Right now we have ideas that we've been tossing around for it, but no actual work has been done on that front. If you have ideas, please send me a PM if it's something specific or just post up general ideas in this thread. For detailed questions I'll have to get feedback from LOst to give you definitive answers, but I'll definitely see what we can do to make things as simple for you guys as is possible on our end.

Hmmm, Visual C++? I'd probably guess it uses Visual Studio solution/project files. I could probably convert that to CMake so that it could work with both MSVC and GCC x86_{32,64}. Since MinGW-w64 is pretty stable now, it should be compilable as 64-bit Windows binaries on the MinGW target.

What are the plans for replacing the the DirectX library dependencies? I've got a few suggestions for replacing that stuff.

For DirectSound, we should replace that with OpenAL. I've had good experience with it. DirectInput should be replaced with SDL. Since we already have an OpenGL output, that part should be okay.

This post has been edited by Conan Kudo: 20 June 2010 - 12:40 AM

[HeartAttack]

I'm pretty sure the proper descriptor for 32-bit software would be x86, and not x32. So "Microsoft Visual C++ 2008 x32 " would actually be "Microsoft Visual C++ 2008 x86 ". I mean, unless I'm just totally crazy. Just an FYI

Anyways, I'm sure a lot of people really appreciate all this info. I know I'm way more excited about this project than I was a few days ago. Keep up all the great work!

[Conan Kudo]

I'm pretty sure the proper descriptor for 32-bit software would be x86, and not x32. So "Microsoft Visual C++ 2008 x32 " would actually be "Microsoft Visual C++ 2008 x86 ". I mean, unless I'm just totally crazy. Just an FYI

Anyways, I'm sure a lot of people really appreciate all this info. I know I'm way more excited about this project than I was a few days ago. Keep up all the great work!

The current marketing is x86, but the proper term would be x86_32, just as x64 is a marketing term for x86_64. They are both x86 architecture, just different variants.

[LOst]

Hmmm, Visual C++? I'd probably guess it uses Visual Studio solution/project files. I could probably convert that to CMake so that it could work with both MSVC and GCC x86_{32,64}. Since MinGW-w64 is pretty stable now, it should be compilable as 64-bit Windows binaries on the MinGW target.

Yep, it uses Visual Studio solution/project files.

What are the plans for replacing the the DirectX library dependencies? I've got a few suggestions for replacing that stuff.

The engine is not designed to depend on a specific library like DirectX. The game calls the active driver to do the work, and if that driver is a software 3D render, it will work too.

For DirectSound, we should replace that with OpenAL. I've had good experience with it. DirectInput should be replaced with SDL. Since we already have an OpenGL output, that part should be okay.

When I program I usually go for the fastest way to the hardware, such as talking to the drivers of the operating system directly, unless it is too complicated (like compiling shaders for different graphics cards) and another layer is needed.

An example is how GDI works in Windows:
You have GDI32.DLL dynamically linked with your program which you must use to draw on your window, and GDI32.DLL will validate the call and make a system call into WIN32K.DLL on the driver side to do the actual work.
But you can also use the newer and "improved?" GDIPLUS.DLL, which is a layer to GDI32.DLL to add object oriented classes. You call GDIPLUS.DLL which will do a set of work and then call GDI32.DLL, and so on...
GDIPLUS is much slower than GDI32.DLL, and it also has some nasty bugs that Microsoft decided to never fix because they saw the flaw in the design and gave up.

This is taken from the English wiki page for SDL:

On Microsoft Windows, SDL uses a GDI backend by default. A DirectX backend is also available. Older versions of SDL used DirectX 5, but SDL 1.2 (the current stable release) requires DirectX 7 by default. Sam Lantinga has stated that he plans to use DirectX 8 in future SDL releases.[

A layer to do things that we are already doing, is not an improvement. Also it doesn't sound very exciting to me, that is currently using Direct3D 9 with shaders! DirectX 8 is so last decade.

Instead of depending on layers that are not designed to work with a Sonic game, a custom engine with its own drivers are used instead. Those driver calls are built specially designed to work with Sonic games, and if that interface can't be provided by a specific platform, the platform cannot support this Sonic game.

You need the right hardware to run Sonic 2HD. If the driver written to support the game is not 100% compatible, it will be cut. That are the rules.
I have already cut alot of things because of limits in today's technology. Usually what was cut had to do with visual apeal.

The engine simply runs its own layer for converting calls to the platform's real drivers. There is no need for another layer.

Note that all of the engine is documented with Doxygen, so that I will not have to take my time to explain all the stuff that is going on.

[GerbilSoft]

I have already cut alot of things because of limits in today's technology. Usually what was cut had to do with visual apeal.

If you want people to take you seriously, cut the bullshit. S2HD is supposed to be a 2D game. What could possibly be missing in "today's technology" that you need for a remake of a 2D game that originally ran on a game console built in 1988?

Also, in case you haven't noticed, SDL supports OpenGL. You were looking at SDL's software rendering subsystem.

Instead of depending on layers that are not designed to work with a Sonic game, a custom engine with its own drivers are used instead. Those driver calls are built specially designed to work with Sonic games, and if that interface can't be provided by a specific platform, the platform cannot support this Sonic game.

The Genesis VDP wasn't specially designed to work with Sonic games, but it looks like Sonic Team got along with it just fine!

This post has been edited by GerbilSoft: 20 June 2010 - 03:27 AM

[Conan Kudo]

Hmmm, Visual C++? I'd probably guess it uses Visual Studio solution/project files. I could probably convert that to CMake so that it could work with both MSVC and GCC x86_{32,64}. Since MinGW-w64 is pretty stable now, it should be compilable as 64-bit Windows binaries on the MinGW target.

Yep, it uses Visual Studio solution/project files.

Converting it to CMake will let anyone generate Visual Studio solutions, MinGW makefiles, or Code::Blocks workspaces so that you can use either Microsoft's Visual C++ compiler or the MinGW compiler toolchain. Additionally, once the game is cross platform in the codebase, CMake can be used to target Linux, Mac OS X, etc.

What are the plans for replacing the the DirectX library dependencies? I've got a few suggestions for replacing that stuff.

The engine is not designed to depend on a specific library like DirectX. The game calls the active driver to do the work, and if that driver is a software 3D render, it will work too.

DirectX is a family of libraries. Direct3D, DirectDraw, DirectInput, DirectSound, and DirectMusic are all DirectX libraries.

For DirectSound, we should replace that with OpenAL. I've had good experience with it. DirectInput should be replaced with SDL. Since we already have an OpenGL output, that part should be okay.

When I program I usually go for the fastest way to the hardware, such as talking to the drivers of the operating system directly, unless it is too complicated (like compiling shaders for different graphics cards) and another layer is needed.

An example is how GDI works in Windows:
You have GDI32.DLL dynamically linked with your program which you must use to draw on your window, and GDI32.DLL will validate the call and make a system call into WIN32K.DLL on the driver side to do the actual work.
But you can also use the newer and "improved?" GDIPLUS.DLL, which is a layer to GDI32.DLL to add object oriented classes. You call GDIPLUS.DLL which will do a set of work and then call GDI32.DLL, and so on...
GDIPLUS is much slower than GDI32.DLL, and it also has some nasty bugs that Microsoft decided to never fix because they saw the flaw in the design and gave up.

This is taken from the English wiki page for SDL:

On Microsoft Windows, SDL uses a GDI backend by default. A DirectX backend is also available. Older versions of SDL used DirectX 5, but SDL 1.2 (the current stable release) requires DirectX 7 by default. Sam Lantinga has stated that he plans to use DirectX 8 in future SDL releases.[

A layer to do things that we are already doing, is not an improvement. Also it doesn't sound very exciting to me, that is currently using Direct3D 9 with shaders! DirectX 8 is so last decade.

Instead of depending on layers that are not designed to work with a Sonic game, a custom engine with its own drivers are used instead. Those driver calls are built specially designed to work with Sonic games, and if that interface can't be provided by a specific platform, the platform cannot support this Sonic game.

You need the right hardware to run Sonic 2HD. If the driver written to support the game is not 100% compatible, it will be cut. That are the rules.
I have already cut alot of things because of limits in today's technology. Usually what was cut had to do with visual apeal.

The engine simply runs its own layer for converting calls to the platform's real drivers. There is no need for another layer.

Note that all of the engine is documented with Doxygen, so that I will not have to take my time to explain all the stuff that is going on.

Two things: First, your source code already has the OpenGL outputs. By using SDL for the OpenGL context, it wouldn't ever use GDI. The second thing was that I was recommending SDL for input, not graphics.

OpenAL, as the sound driver, provides hardware accelerated sound when possible, while gracefully falling back to regular software processed sound if it isn't supported. However, DirectSound has no support for hardware accelerated sound anymore. Microsoft removed it in Windows Vista.

Also, doxygen isn't very useful when we cannot access the source tree and the documentation.

This post has been edited by Conan Kudo: 20 June 2010 - 03:32 AM

[AamirM]

When I program I usually go for the fastest way to the hardware, such as talking to the drivers of the operating system directly, unless it is too complicated (like compiling shaders for different graphics cards) and another layer is needed.

Hey, I've got an awesome suggestion. Ditch the operating system layer all together! Make the game bootable, write drivers for the capable enough hardware for this engine yourself. And the good news is, you have done most of the work to do that ALREADY! No more stupid layers to slow you down and make your life easier. WIN WIN!

This post has been edited by AamirM: 20 June 2010 - 04:08 AM

[test-object]

There has been much more activity recently in the level art, thanks in no small part to MaximusDM's efforts and Test-Object coming back into the picture.

Oh, MaximusDM HAS done a bunch of work, but me having made a lot for the project lately is bullshit. :P
I did more than other people yes, but you can't honestly call it a lot. I've been quite busy lately but you can expect more later in the summer vacation.

This post has been edited by test-object: 20 June 2010 - 04:16 AM

[DigitalDuck]

I have already cut alot of things because of limits in today's technology. Usually what was cut had to do with visual apeal.

If you want people to take you seriously, cut the bullshit. S2HD is supposed to be a 2D game. What could possibly be missing in "today's technology" that you need for a remake of a 2D game that originally ran on a game console built in 1988?

I have to absolutely triple-echo this sentiment.

Ports of the game's engine have been made. Some of these ports have used images, in some form, as tiles for the game. Surely nearly everything to do with visual appeal involves simply replacing those tiles with new, remade tiles. We have .PNG files, capable of storing 32-bit colour and transparencies with lossless compression. .APNG files can store animated versions. We have hard drives more than capable of storing hundreds of times more than the entire game should take up. Any visual "effects" should take up minimal CPU to overlay/replace these already existing tiles, and this includes shadows, reflections, and sun glare. There's no reason it can't be done in real-time.

So, as GS said, what could possibly be missing in "today's technology" that you need for a remake of a 2D game that originally ran on a game console built in 1988?

[The Growler]

Just a seriously crazy idea I've just thought of, but what if we did something along the lines of what the Monkey Island Special Editions do, by being able to switch between HD and classic modes?

But then again, it could take up far too much memory to basically have 2 games playing at once (and it's probably not doable anyway).

This post has been edited by The Growler: 20 June 2010 - 10:51 AM

[DigitalDuck]

But then again, it could take up far too much memory to basically have 2 games playing at once (and it's probably not doable anyway).

You don't need two games playing at once. All that's needed is two sets of graphics (and sounds) for the game, and switching from one to the other at the press of a button. I'm not sure how quickly the change can take place, but it's certainly doable.

[test-object]

Going further upon my Special Stage Whacky Idea Show, I sure would love making a Special Stage myself :3

...should we have time for the coding.