---== Sonic Engine To End All Sonic Engines ==---

[MidimanNull]

Question.

When you earlier said that palletes were involved in this game? What about live recoloring ( ie: a change in color as your underwater )

[saxman]

Well the PZF format will support more file data than acts that can exist in the PZF file. The reason for this is to give the designer the abbility to have multiple palettes for an act. If at some point you need to swap palette data, you can do that. With script files, you'll be able to change the colors individually if needed.

But if I decide to upgrade to 15 or 16-bit color, then there likely won't be any use for palette files and you'll have access to all the colors throughout the entire game. Though even so, I would still be supporting color changing methods through scrip files, as well as water maps which I'm currently using to make the game go "oh, these group of colors need to change to this other group of colors".

The short answer to your question is "it'll be supported".

EDIT:

Okay I'm considering the posibility of offering a choice to designers. I'm thinking my engine would have the best possible benefits for both sides if it was to allow games to be created using 256 -OR- 65536 colors. Initially I thought that would be bad because it would create incompatibilities, but then I realized the modes would never have to talk to one another, so incompatibilities wouldn't be an issue. What do you guys think about this? Purists want 256, SFGHQers want 65536... maybe I can do both?

[MidimanNull]

I also assume Sin/Cos is supported as well as other math?

cant get enough of those moving platforms

[saxman]

It might very well be supported. Though I have a table setup in my engine consisting of 256 different Sin/Cos floating-point values. Let me show you what I have and maybe people can comment if it'll be enough for what they would want to do with the engine. If it won't, perhaps supporting Sin/Cos would be important.

// This table is used with calculating player->Angle
const float	AngleConst[] = {
	// AngleConst[n] = Sin(90/64*n)

	// Should NOT use any more than one-thousandths precision.
	// Not having great enough precision error will throw some
	// values off from the original Sonic engine. A perfect
	// example is AngleConst[0x3F].
	0.000,	0.025,	0.049,	0.074,	0.098,	0.122,	0.147,	0.171,
	0.195,	0.219,	0.243,	0.267,	0.290,	0.314,	0.337,	0.360,
	0.383,	0.405,	0.428,	0.450,	0.471,	0.493,	0.514,	0.535,
	0.556,	0.576,	0.596,	0.615,	0.634,	0.653,	0.672,	0.690,
	0.707,	0.724,	0.741,	0.757,	0.773,	0.788,	0.803,	0.818,
	0.831,	0.845,	0.858,	0.870,	0.882,	0.893,	0.904,	0.914,
	0.924,	0.933,	0.942,	0.950,	0.957,	0.964,	0.970,	0.976,
	0.981,	0.985,	0.989,	0.992,	0.995,	0.997,	0.999,	1.000,
	1.000,	1.000,	0.999,	0.997,	0.995,	0.992,	0.989,	0.985,
	0.981,	0.976,	0.970,	0.964,	0.957,	0.950,	0.942,	0.933,
	0.924,	0.914,	0.904,	0.893,	0.882,	0.870,	0.858,	0.845,
	0.831,	0.818,	0.803,	0.788,	0.773,	0.757,	0.741,	0.724,
	0.707,	0.690,	0.672,	0.653,	0.634,	0.615,	0.596,	0.576,
	0.556,	0.535,	0.514,	0.493,	0.471,	0.450,	0.428,	0.405,
	0.383,	0.360,	0.337,	0.314,	0.290,	0.267,	0.243,	0.219,
	0.195,	0.171,	0.147,	0.122,	0.098,	0.074,	0.049,	0.025,
	0.000,	-0.025,	-0.049,	-0.074,	-0.098,	-0.122,	-0.147,	-0.171,
	-0.195,	-0.219,	-0.243,	-0.267,	-0.290,	-0.314,	-0.337,	-0.360,
	-0.383,	-0.405,	-0.428,	-0.450,	-0.471,	-0.493,	-0.514,	-0.535,
	-0.556,	-0.576,	-0.596,	-0.615,	-0.634,	-0.653,	-0.672,	-0.690,
	-0.707,	-0.724,	-0.741,	-0.757,	-0.773,	-0.788,	-0.803,	-0.818,
	-0.831,	-0.845,	-0.858,	-0.870,	-0.882,	-0.893,	-0.904,	-0.914,
	-0.924,	-0.933,	-0.942,	-0.950,	-0.957,	-0.964,	-0.970,	-0.976,
	-0.981,	-0.985,	-0.989,	-0.992,	-0.995,	-0.997,	-0.999,	-1.000,
	-1.000,	-1.000,	-0.999,	-0.997,	-0.995,	-0.992,	-0.989,	-0.985,
	-0.981,	-0.976,	-0.970,	-0.964,	-0.957,	-0.950,	-0.942,	-0.933,
	-0.924,	-0.914,	-0.904,	-0.893,	-0.882,	-0.870,	-0.858,	-0.845,
	-0.831,	-0.818,	-0.803,	-0.788,	-0.773,	-0.757,	-0.741,	-0.724,
	-0.707,	-0.690,	-0.672,	-0.653,	-0.634,	-0.615,	-0.596,	-0.576,
	-0.556,	-0.535,	-0.514,	-0.493,	-0.471,	-0.450,	-0.428,	-0.405,
	-0.383,	-0.360,	-0.337,	-0.314,	-0.290,	-0.267,	-0.243,	-0.219,
	-0.195,	-0.171,	-0.147,	-0.122,	-0.098,	-0.074,	-0.049,	-0.025
};

const float	AngleConstY[] = {
	// AngleConst[n] = Sin(90/64*n)

	// Should NOT use any more than one-thousandths precision.
	// Not having great enough precision error will throw some
	// values off from the original Sonic engine. A perfect
	// example is AngleConst[0x3F].
	0.000,	0.000,	0.001,	0.003,	0.005,	0.008,	0.011,	0.015,
	0.019,	0.024,	0.030,	0.036,	0.043,	0.050,	0.058,	0.067,
	0.076,	0.086,	0.096,	0.107,	0.118,	0.130,	0.142,	0.155,
	0.169,	0.182,	0.197,	0.212,	0.227,	0.243,	0.259,	0.276,
	0.293,	0.310,	0.328,	0.347,	0.366,	0.385,	0.404,	0.424,
	0.444,	0.465,	0.486,	0.507,	0.529,	0.550,	0.572,	0.595,
	0.617,	0.640,	0.663,	0.686,	0.710,	0.733,	0.757,	0.781,
	0.805,	0.829,	0.853,	0.878,	0.902,	0.926,	0.951,	0.975,
	1.000,	0.975,	0.951,	0.926,	0.902,	0.878,	0.853,	0.829,
	0.805,	0.781,	0.757,	0.733,	0.710,	0.686,	0.663,	0.640,
	0.617,	0.595,	0.572,	0.550,	0.529,	0.507,	0.486,	0.465,
	0.444,	0.424,	0.404,	0.385,	0.366,	0.347,	0.328,	0.310,
	0.293,	0.276,	0.259,	0.243,	0.227,	0.212,	0.197,	0.182,
	0.169,	0.155,	0.142,	0.130,	0.118,	0.107,	0.096,	0.086,
	0.076,	0.067,	0.058,	0.050,	0.043,	0.036,	0.030,	0.024,
	0.019,	0.015,	0.011,	0.008,	0.005,	0.003,	0.001,	0.000,
	0.000,	0.000,	-0.001,	-0.003,	-0.005,	-0.008,	-0.011,	-0.015,
	-0.019,	-0.024,	-0.030,	-0.036,	-0.043,	-0.050,	-0.058,	-0.067,
	-0.076,	-0.086,	-0.096,	-0.107,	-0.118,	-0.130,	-0.142,	-0.155,
	-0.169,	-0.182,	-0.197,	-0.212,	-0.227,	-0.243,	-0.259,	-0.276,
	-0.293,	-0.310,	-0.328,	-0.347,	-0.366,	-0.385,	-0.404,	-0.424,
	-0.444,	-0.465,	-0.486,	-0.507,	-0.529,	-0.550,	-0.572,	-0.595,
	-0.617,	-0.640,	-0.663,	-0.686,	-0.710,	-0.733,	-0.757,	-0.781,
	-0.805,	-0.829,	-0.853,	-0.878,	-0.902,	-0.926,	-0.951,	-0.975,
	-1.000,	-0.975,	-0.951,	-0.926,	-0.902,	-0.878,	-0.853,	-0.829,
	-0.805,	-0.781,	-0.757,	-0.733,	-0.710,	-0.686,	-0.663,	-0.640,
	-0.617,	-0.595,	-0.572,	-0.550,	-0.529,	-0.507,	-0.486,	-0.465,
	-0.444,	-0.424,	-0.404,	-0.385,	-0.366,	-0.347,	-0.328,	-0.310,
	-0.293,	-0.276,	-0.259,	-0.243,	-0.227,	-0.212,	-0.197,	-0.182,
	-0.169,	-0.155,	-0.142,	-0.130,	-0.118,	-0.107,	-0.096,	-0.086,
	-0.076,	-0.067,	-0.058,	-0.050,	-0.043,	-0.036,	-0.030,	-0.024,
	-0.019,	-0.015,	-0.011,	-0.008,	-0.005,	-0.003,	-0.001,	0.000
};[/CODE]

I forget exactly how the second set of values are calculated. The documentation on the first set is correct, but on the second set it's different. I forgot to document what I did to get the second set of values T_T

[DimensionWarped]

Rather to use C or C++ is really opinion that is different for anyone. What it all comes down to is "what do you like better?". I like C... I like C++ is pointless because I never use any of the extra stuff involved in it. Of course technically you could say I use C because I use the line-comments which weren't part of the original ANSI C standard and were first seen in C++... but that's as far as I go. I can do all the same stuff in C++ using the C way of doing things.

I relate this very much to playing saxophone... some people like to play a note using one fingering, but then someone else comes along and says "you should play it using the other fingering"... the way I see it is if I can play that note my way and it works and I sound just as good (or better) as the other method, then I should continue doing it the way I'm most comfortable doing it.

So I'm more comfortable in C and can program ProSonic just fine using it. There's no right or wrong way or right/wrong programming language to use for anything. It's all preference, and I prefer C. C++ doesn't make my programs any better or any easier to write.

Well then I suppose I just have to say that playing guitar with only 2 fingers will only take you so far. You'll have to use the whole hand if you want to play Acoustic Alchemy songs... and that isn't an opinion. While playing with the whole hand may mean scrapping a lot of what is familiar to you for something that is difficult, it pays off once you've gained the mastery over your hand for that to become what is familiar and you can play the harder songs... and play what you used to know faster and better.

Maybe I'm just making my own little music analogy to programming though.

And sure, OOP may just be the two most retarded fingers that you have... both on your non-dominant hand even. But I'm still rather fond of what they can do when used by someone who has mastery over them.

[Damizean]

It might very well be supported. Though I have a table setup in my engine consisting of 256 different Sin/Cos floating-point values. Let me show you what I have and maybe people can comment if it'll be enough for what they would want to do with the engine. If it won't, perhaps supporting Sin/Cos would be important.

...[/CODE]

I forget exactly how the second set of values are calculated. The documentation on the first set is correct, but on the second set it's different. I forgot to document what I did to get the second set of values T_T

Aren't you using allegro? Because allegro has built-in fixed point maths lib, wich is portable to non-FPU systems, and has all the stuff to handle matrixes and trig.

[saxman]

Yes I am, but I used my own tables to cut down on the necessary math to keep the program as fast as possible. My tables have the values I need automatically rounded the way they are needed and easy to point to (e.g. if the slope value is 10 (which translates to Sin(90/64*10)), I can point to that value in the table and get the number I need without any math to get to it). It also cuts down on unnecesary repetitions in the math formulas throughout my engine (because they're all based on the same rounding and 256 value model).

But perhaps allowing designers to access the Sin/Cos tables in allegro through scripting wouldn't be a bad idea. I am personally biased against them because the original Sonic games never had that level of precision and accuracy, but perhaps others besides myself will find them useful. So we'll see.

[Aerosol]

I don't get it sax. you DONT need to be programmer to make a game? does that mean the game that is made by a non programmer will be pretty skeletal in terms of features or am i just missing something.

[USC]

I think he means that you won't need to know a lot to make a game with this engine. Like, the difference between someone who can use MMF and someone...who can make a Sonic game engine from scratch.

[Damizean]

You'll only have to learn the Sax Script stuff to customice the game

[Aerosol]

customize in what way though. how far does the customization extend the click and drag capabilities?

[USC]

I don't think it's click and drag. I think what happens is...Saxman will release ProSonic, and when you make a new project, you'll have a "template" engine already in place. Then, once you've learned the basics of Sax's special script, you'll be able to add/remove/change anything you want.

[Aerosol]

ah, fair enough. As long as fangames still require a fair deal of effort.

[saxman]

Wait a second... I'm going to step in and try to prevent any speculation from coming around!

The ProSonic engine won't require any programming. This means that you can design levels, use objects that have either been packaged with ProSonic or objects you download from the internet (which is an effort I'll push for when it's released), setup basic properties for the game, etc. It'll be flexible and editable enough without any programming to make a game of your own. If you want to get advanced and actually script your own objects without borrowing existing ones or rewrite code in the engine, then you'll need to do a little programming. But I disagree that making an engine where it requires people to have lots of advanced skills is a requirement -- that's an engine setup for failure. This engine is intended for all audiences. It's gotta be really easy to work with, but flexible enough to keep the advanced users happy.

[Aerosol]

let me rephrase then. I'm happy as long as GOOD fangames require a good deal of effort. By scripting your own objects I assume you mean making new bosses, enemies, and general level gimmicks that aren't in the genesis sonic games?

[saxman]

I guess I'm confused because I thought any good game required work. I'm not quite following you there. And for scripting objects, you're correct. Some of the objects from the Genesis games will be packaged with ProSonic -- the most basic ones like rings and such. 3 objects have been programmed for it -- ring, beach ball, and a steel reinforcement. Designers can choose to use these objects, or they can replace them with their own. At least 255 objects will be supported... I'm still wondering if I should support even more.

[MidimanNull]

255 -> 256.

Numbers Of Global Objects / Category Limits = Objects for each Category.

256 / 8 = 32

awesomeness.

[saxman]

Well keep in mind that every object will have flags. There are a total of 8 bits of flags (0-255)... so if you were to program an object that acts or looks differently depending on flags set, you could potentially have more categories. For example, in Sonic 2, a monitor object can be a super ring, super sneakers, shield, invincibility, teleportation, 1-up, or Robotnik. It's one object, but it takes many forms depending on the flags set.

[MidimanNull]

That is the simplest yet most effective feature ever.

[saxman]

There is what my PZF archiver looks like so far. It's beginning to have some functionality. There's still lots more work to do to it though. I'm going for a WinTex-style editor.

[saxman]

Another good ol' update on my blog. Filter files are now supported, and they can be created by designers without any programming knowledge =) And multiple resolutions will be supported -- 320x200, 320x240, 640x400, 640x480, with 8-bit and 16-bit color modes.

[Asuma]

Fliter files?

[MidimanNull]

Filters = Graphical Effects.

IE Motion Blur.

[saxman]

What Midiman said. Filters are used for things like making water seem more watery (e.g. Labyrinth Zone - S1), or making a level that's on fire seem really hot (e.g. Angel Island - S3).

Filters won't be limited to this though. There will actually be multiple 'types' of filters. This is just one type. Other types would for example allow scrolling effects (e.g. the mountains in the far background of Hill Top). Those effects are used especially heavy in Sonic 3. Why would you both using a scrolling filter instead of using more background planes? Because a scrolling filter would be a heck of a lot faster =) Using too many planes risks slowing the game down, especially on older machines.

But anyway, right now the filters files I've mentioned are indeed for the motion effects.

[hRook]

How about sample based music synthesizing? Sonic and things like that all have their music, which is a MIDI at heart (sequenced music file, that's how they're ripped so easily), but it's all done with the samples on the cartridge. A killer feature would be setting up a music format that would allow you to import midi and use low-sized samples for the music. Then you could set loop points in the song so you don't have those obnoxious looping pauses.

I'd be more than willing to help out.