Possible ALIVE project...

[gishygleb]

I have a small tip. Make the design dark to make it fabulous. Like not black letters on white, but white letters on black; not beige borders on gray, but dark violet borders on navy; etcetera.

[RoryF]

What do you mean? The documentation and LVLX files are all plain text; it's up to whatever you use to read them to make them look like that.

[gishygleb]

The design of the engine, that you are going to employ in future.

[RoryF]

I doubt there'll be anything "fabulous" included with the engine. I'll explain here what will be included:

• The engine executable (obviously).
• The default folder structure (not 100% necessary).
• A folder with .dlls for the objects used in AO and AE ready to be used (if you want to use them that is).
• TEXDEFs and ANIMDEFs for those objects.
• Possibly a LVLX file for loading the demos of AO/AE and a guide on how to set it up (providing you have the original games' assets).

In order to load a game, the engine will start in a CLI. Then you'd have to tell it what level you want to load, I will probably include the loading of arguments on startup though so a launcher could be made for ease of use.

Edit:

Here is a first draft of the objects doc.

Edit 2:

Oh, and I also have to figure out a good way of handling collision data; probably all of it (besides the co-ordinates) will be handled in the same way ObjectVars will. OH OH OH I forgot that I wrote List that's not what I'll be using - fixed that. Meta is a class that simply is:

public class Meta
{
public string Name;
public object Contents;
}

Essentially a variable thingy - meaning no hard-coded crap! I feel like a genius.

[gishygleb]

Maybe, it is just me, but OHMYOROCHI, THERE IS TOO MUCH DESCRIPTION, TOO SOLID, I CAN NOT READ IT WELL.

That was not an insult. It would be better if you could cut those a bit. As there are ~8 lines of code and OHMYOROCHI AMOUNT of description... OHMYOROCHI...

[RoryF]

Of course there's description, that's kind of the point in making documentation. It's not that hard to understand either, comments on each part are written next to the :: bits.

Edit:

Updated the doc again with CAMCode...

Oh and I changed the ID after looking around stuff in Paul's editor for the original games.

Edit 2:

Updated again, this time I have actually added the stuff required for TEXDEFs and ANIMDEFs.

Edit 3:

Alright... after a little Quake 3 I finally got the LVLX stuff written up, I've spent a lot of that time checking if it *will* work with the way I have this planned. I'm sure that it will, hopefully little will change in LVLX besides the LVLINFO section (although I can't be certain, there's got to be at least one thing I've missed).

Here is the LVLX Format stuff.

I aim to actually work on the tools next, I've had thoughts on what they should work like. I'm sure it'll be good, the TEXDEFs and ANIMDEFs will be done first, then the level editor. Bear in mind the level editor will take a lot of work, since I'll have to plan out how the plugin interface will work and also how it will look in general.

I really need to save that grid CAM somewhere I can't lose it, it's getting annoying looking for the damn thing, and it could come in handy too!

[mlg man]

If Paul is willing to share the code that decodes the games CAM files, I can happily supply a C# version for XNA ? Wouldn't it be easier if the open source port tries to use as many original files as possible?

[RoryF]

You mean ripping the CAM files when it loads? I guess you could if Paul thinks it's a good idea. But yeah the plan is to obviously not supply any of the actual game's content, only the AI scripts and stuff for the objects themselves (and like I said before, possibly a LVLX file for the AO/AE demos).

Edit:
Remember that it will already use the original game's sprites extracted from Paul's decoder in their normal bitmap form; that's the reason the transparent colour part is supplied in TEXDEFs in order to key out the black.

[mlg man]

Having the original games sprites load from the original files would be even better too. With a custom ContentManager class in XNA you could load them like you would with any normal texture file.

Edit: Also when loading the animations from the original BAN/BND files, transparency will already be added to the textures. So you don't even need to supply a Color Key.

[gishygleb]

I would double that, but it is obvious.

OMO, are you alive, Mlg???

[mlg man]

OMO, are you alive, Mlg???

No I'm dead.

And good news for using XNA 4. Your engine can be very cross platform.
XNA Games can be ported to Mac and Linux using MonoGame; Heck even iOS, with a license of course though.

So if Cross platform is what you're aiming for, I'd Google MonoGame and do some research in converting your XNA Project to it. It's not THAT hard. All the code stays the same. Only things like shaders become a little more harder to do. (Personally Speaking)

If you aren't too sure on how to do this, then I'd just keep going as you are right now. You can always convert your project to MonoGame at any time. But it just makes things easier if you did it now.

[gishygleb]

XNA is no more supported by Microsoft. It is going to be unemployed in future. That was a real shock for me a year ago. Maybe, Mono shall be a chance for revival, but we can not expect something marvellous from a not-really-known engine.

Do not forget commas after "No,", "Yes,", please.

[RoryF]

Having the original games sprites load from the original files would be even better too. With a custom ContentManager class in XNA you could load them like you would with any normal texture file.

Edit: Also when loading the animations from the original BAN/BND files, transparency will already be added to the textures. So you don't even need to supply a Color Key.

That's how the test worked when I made it, it creates a memory stream to obtain the bitmaps, keys out the pixels and then loads them into a Texture2D object using SetData(Colour[] Data). Slow, but effective.

If you can figure out a way to read them straight from transparent resources, I'd be glad to add it. Of course the bitmap alternative is there if someone really wants to use a bmp for whatever reason.

No I'm dead.

And good news for using XNA 4. Your engine can be very cross platform.
XNA Games can be ported to Mac and Linux using MonoGame; Heck even iOS, with a license of course though.

So if Cross platform is what you're aiming for, I'd Google MonoGame and do some research in converting your XNA Project to it. It's not THAT hard. All the code stays the same. Only things like shaders become a little more harder to do. (Personally Speaking)

If you aren't too sure on how to do this, then I'd just keep going as you are right now. You can always convert your project to MonoGame at any time. But it just makes things easier if you did it now.

I've heard of Mono before, sounds good to me; I'll look into when it comes to working on the XNA stuff.

XNA is no more supported by Microsoft. It is going to be unemployed in future. That was a real shock for me a year ago. Maybe, Mono shall be a chance for revival, but we can not expect something marvellous from a not-really-known engine.

Do not forget commas after "No,", "Yes,", please.

Whilst it's not supported by Microsoft, it's not dead, there are ways to get it on Windows 8 even if they don't want you to (I know it's possible; I used to make XNA stuff on my spare Windows 8 laptop).

If it comes to being as dead as you say, then it's a good thing it's going to be open-source.

[mlg man]

XNA is no more supported by Microsoft. It is going to be unemployed in future. That was a real shock for me a year ago. Maybe, Mono shall be a chance for revival, but we can not expect something marvellous from a not-really-known engine.

Do not forget commas after "No,", "Yes,", please.

It's no longer supported by Microsoft, but the open source version, MonoGame, is always being updated and ported to different platforms. And if somethings wrong with it, you can fix it yourself.

[gishygleb]

I hope too, but this hope is glimmering. MonoDevelopers are not absolutely stable. Like any low-term firm. But well. I would think dimensionally and consider your opinion.

Go for XNA.

[RoryF]

I'm currently working on the GUI for the actual tools now. Thinking about putting TEXDEF, ANIMDEF and LVLX building all into one program, or would that be too complicated?

They will be switchable from a menu strip at the top. I'll get the first two working for now though and I will see about LVLX later.

[mlg man]

I'm currently working on the GUI for the actual tools now. Thinking about putting TEXDEF, ANIMDEF and LVLX building all into one program, or would that be too complicated?

They will be switchable from a menu strip at the top. I'll get the first two working for now though and I will see about LVLX later.

What ever is easiest for you to implement.

[RoryF]

LVLX will obviously take the longest, so I'm doing TEXDEFs first and then ANIMDEFs next in their own editor. There's too much to LVLX to really fit it in the same program to be honest.

EDIT VERY LATE:

I have indeed made the tools and stuff now. In fact a while back.

The thing is I'm working to learn GL stuff to make this easier and faster (performance-wise). XNA is good, but there are a lot of parts that are too slow and the only fast ways are meant for one-off processes.

It will be a bit before work on the engine kicks off, but trust me when I say it's literally GL I'm working on.