Basic tools/source code now available for Dune support

[monsieurouxx]

What do you mean "recent"? Each engine is different, as it does what it's supposed to do in a different way,

Yes but ScummVM meta-engine's philosophy and classes have evolved. Some older inner engines will use primitive functions offered by early ScummVM versions, and other engines (that have been written recently) use the latest versions of ScummVM's features. Do you get me? Or am I mistaken?

I read the whole thread in your boards (...)

Hey dude you're crazy! All you need to do is to download the tech-demo I've posted above and adapt THAT code to ScummVM. It's made of only a few uber-simple classes, and doesn't even embed the sound technology. And the Voxel thing is not really needed, it's just there to add a bit of fun to the whole thing - just ignore it.

[monsieurouxx]

Hey all, I've got a question :

Provided we want to do some scripting in Lua for our engine,
Is there an easy way to use the Lua-related part of the Grim Fandango engine for our own purpose (and therefore re-use some exisiting ScummVM code), or do you think it would be simpler to embed a mainstream, standalone Lua library in our engine for ScummVM?
I know it's a tough question, if you think there is no simple answer to it, then I'll read the Grim Fandango engine with more attention.

[md5]

Hey all, I've got a question :

Provided we want to do some scripting in Lua for our engine,
Is there an easy way to use the Lua-related part of the Grim Fandango engine for our own purpose (and therefore re-use some exisiting ScummVM code), or do you think it would be simpler to embed a mainstream, standalone Lua library in our engine for ScummVM?
I know it's a tough question, if you think there is no simple answer to it, then I'll read the Grim Fandango engine with more attention.

We do have a LUA implementation for Broken Sword 2.5, which actually uses it. Why do you need LUA, if the original game didn't use it?

[md5]

Hey dude you're crazy! All you need to do is to download the tech-demo I've posted above and adapt THAT code to ScummVM. It's made of only a few uber-simple classes, and doesn't even embed the sound technology. And the Voxel thing is not really needed, it's just there to add a bit of fun to the whole thing - just ignore it.

That's not the best way to make friends, is it?

The "tech demo" does not contain any IDA files, someone in that thread said he started reversing the executable, which is why I ask... where is that IDB file? I guess it's gone now?

[monsieurouxx]

Why do you need LUA, if the original game didn't use it?

Let's put it another way : Why should we make the game logic in C++, when it's super-simple (let's be honest, Dune is a very primitive Adventure game and Strategy game), and when making it in Lua would allow newbies to easily change some stuff in the game without having to recomplie the whole project? (think of all possible additional campains, storylines, etc.). I'm thinking mods here.

Anyway, that's not the priority right now. My qyestion is more R&D for the future. So, do you think re-using your "Broken-Sword interface between Lua and ScummVM" code would make sense, or would it only be complicating things?

[monsieurouxx]

Hey dude you're crazy!

That's not the best way to make friends, is it?

I'm not sure what you mean All I said was: "be as lazy as you please" (because I perfectly realize that it's not correct to come to a forum and ask other people to do stuff, except for fun)

The "tech demo" does not contain any IDA files, someone in that thread said he started reversing the executable, which is why I ask... where is that IDB file? I guess it's gone now?

I can have a look into it and contact the original authors of those tweaks, but keep in mind that in the meantime we've had a better understanding of the technologies used, and we're now using mostly plain C++ code, and exisiting open-source libraries.
So, for the graphics, definitely stick to the HSQ unpacker and reader present in the tech demo.
And if you really want to try doing things woth the sound, I'd recommend contacting the "Honza.c" member of the Dune2k forum, who's definitely the guy who knows the most about that. It'd be a pity if you made something and if he made something else in the meantime -- he mentionned the Mame chip emulator 2 days ago.

[md5]

I can have a look into it and contact the original authors of those tweaks, but keep in mind that in the meantime we've had a better understanding of the technologies used, and we're now using mostly plain C++ code, and exisiting open-source libraries.
So, for the graphics, definitely stick to the HSQ unpacker and reader present in the tech demo.
And if you really want to try doing things woth the sound, I'd recommend contacting the "Honza.c" member of the Dune2k forum, who's definitely the guy who knows the most about that. It'd be a pity if you made something and if he made something else in the meantime -- he mentionned the Mame chip emulator 2 days ago.

We already have a working Adlib and MT-32 driver, as well as our own MT-32 emulator (munt), together with a working VOC player. So, these are all already done.

If you are serious about this, then an SVN repo will be needed, to avoid duplicate work and organize your work. I suppose we can provide a private SVN repo, this has been done in the past for other engines. Contact sev about this (sev AT scummvm DOT org).

[fingolfin]

What would that random mysterious volunteer gain from writing code that is meant to give you a kick start?

Once again, considering how active the community is, I thought some Dune fan boy (like me) would feel happy to do it, just for glory's sake. That's what I would do. As you said, for someone experienced, it takes only 15 minutes.
However after your updates I'll do a new attempt myself.

Yes, it took me only 15 minutes, and it would take you more. But if I now sent you the result (which was created using copy&paste anyway), in the form of, say, a .diff / patch file, then, yes, you'd save some time -- but you'd get a bunch of code you haven't read, and which you don't understand at all. I think it's much better for you if you follow the howto; this way at least you know which files were touched, and what was put into them. Based on what you write, it seems you are hoping for a basic minimal engine that you can then extend. But how do you plan to extend the code, if you don't understand it? It would be rather problematic... so you'd be forced to dive into that code anyway. So, I think overall you will save a lot more time if you work on this yourself, then hoping for an automatic solution by somebody else .

One last question : Of all the engines implemented in ScummVM, which one is the most recent and uses the most recent ScummVM conventions, implementations and technologies?

Filipos already answered to this, and I can only agree with him. Just pick a simple (i.e. small engine) and look at that.

In the end, you'll have to develop your own style -- but make sure to follow our code formatting conventions.

It's not important to support all the advanced features from the start, indeed, often new engines don't support them at all, and only get support for them later on, if at all. Our Wiki contains an overview over most of the advanced engine features and which engines implement them.

In general, take a look at the Developer Central in our Wiki.

[monsieurouxx]

If you are serious about this, then an SVN repo will be needed

I've created one a long time ago ( https://dunerevival.dev.java.net/ ) but it turned out that, considering the pace of progress so far, it worked better allowing every contributor creating little snippets of their own, and then letting them putting them together, following their inspiration.

I think we'll be reaching the required level of maturity when we'll have a ScummVM project that can:
- display one single Dune sprite
- play one single Dune tune
- (optional) display one single "Hello world" message interpreted from a Lua file.

Then we'll start considering "distributed" work.

Do you think I'm overlooking something?

[monsieurouxx]

So, I think overall you will save a lot more time if you work on this yourself

Thanks for your suggestions! I'll be sure to follow them.

[md5]

Why do you need LUA, if the original game didn't use it?

Let's put it another way : Why should we make the game logic in C++, when it's super-simple (let's be honest, Dune is a very primitive Adventure game and Strategy game), and when making it in Lua would allow newbies to easily change some stuff in the game without having to recomplie the whole project? (think of all possible additional campains, storylines, etc.). I'm thinking mods here.

Anyway, that's not the priority right now. My qyestion is more R&D for the future. So, do you think re-using your "Broken-Sword interface between Lua and ScummVM" code would make sense, or would it only be complicating things?

Because we have a stance to mimic the original game behavior, so rewriting it all in LUA won't be the same game. As Max (fingolfin) said, you need to actually understand what you're doing, instead of blindly rewriting the game logic in LUA from the beginning on your own. Also, LUA has a large footprint for small devices...

[md5]

If you are serious about this, then an SVN repo will be needed

I've created one a long time ago ( https://dunerevival.dev.java.net/ ) but it turned out that, considering the pace of progress so far, it worked better allowing every contributor creating little snippets of their own, and then letting them putting them together, following their inspiration.

I think we'll be reaching the required level of maturity when we'll have a ScummVM project that can:
- display one single Dune sprite
- play one single Dune tune
- (optional) display one single "Hello world" message interpreted from a Lua file.

Then we'll start considering "distributed" work.

Do you think I'm overlooking something?

Little snippets without code formatting will turn everything into an ugly jigsaw puzzle, with each part of the finished code being different than the rest.

As for your repo: that's what you did on your own project, but if you are considering a ScummVM engine, you will need a separate repository for it.

I could help with this, but I'm busy with personal matters till the middle of the month. But as I said, the main problem isn't to get a glorified resource viewer for the game. It's to actually get the original game logic to work properly - and not rewrite it from scratch in another language

[monsieurouxx]

Because we have a stance to mimic the original game behavior, so rewriting it all in LUA won't be the same game.

I don't understand what you're saying? The behavior of the game does not depend on the technology we use to implement it???
Our primary goal is of course to re-create the exact same game logic as the original Dune game, except it would be in Lua instead of some C/Assembly mix. the rest is only anticipation.

As Max (fingolfin) said, you need to actually understand what you're doing, instead of blindly rewriting the game logic in LUA from the beginning on your own.

What I mean by "game logic" is strictly the game events and AI (not the settings, sound, graphic rendering, localization, etc.). The fact that my knowledge of ScummVM is still primitive is not the reason why I want to use Lua!

Also, LUA has a large footprint for small devices...

That's an excellent reason. But I'm not too worried about that, as it's not our primary target either.

[monsieurouxx]

Little snippets without code formatting will turn everything into an ugly jigsaw puzzle, with each part of the finished code being different than the rest.

As for your repo: that's what you did on your own project, but if you are considering a ScummVM engine, you will need a separate repository for it.

(...)The main problem isn't to get a glorified resource viewer for the game. It's to actually get the original game logic to work properly - and not rewrite it from scratch in another language

I've given my reasons. It's a short-term strategy, the long-term goal being to have a fully-functional game engine. But our project hasn't reached the sufficient critical mass for a SVN repository. Don't worry, that will come.

[md5]

Because we have a stance to mimic the original game behavior, so rewriting it all in LUA won't be the same game.

I don't understand what you're saying? The behavior of the game does not depend on the technology we use to implement it???

Our primary goal is of course to re-create the exact same game logic as the original Dune game, except it would be in Lua instead of some C/Assembly mix. the rest is only anticipation.

Of course it does. All of the games we support are either using the original game scripts for their logic, or, in the rare cases of hard-coded logic, a reverse-engineered script logic, which is usually 100% what the original did. It's typical to separate the game logic and write it in some scripting language, but in this case you're trying to open a door with a sledgehammer: you're taking a heavyweight language (LUA) to rewrite a game logic which might not be that complex after all. So again, I'm not convinced that LUA is the right tool in this case.

What I mean by "game logic" is strictly the game events and AI (not the settings, sound, graphic rendering, localization, etc.). The fact that my knowledge of ScummVM is still primitive is not the reason why I want to use Lua!

Game events and AI are the game logic in a game A settings screen, a sound player and a graphics renderer have no inherent logic in them. And by logic I mean something like: "if the player clicks on that region, do this. If he uses item A with B, do this. If time X has arrived, do this". This is what separates an actual game from a resource viewer...