No Mutants Allowed

[mvBarracuda]

Good news for the whole IanOut community Yesterday, I had the chance to talk with Sztupy about the upcoming IanOut release. So lets get started.

At the moment there are exams @ his university so there is only spare time to work on IanOut. Nevertheless the exams will be finished end of January / beginning of February; so Sztupy will have more time to finish the release. Because of the release delays in the past, Sztupy decided to change the release policy a bit.

[...]

Read the full story here: http://ianout.nma-fallout.com/newhp/english/index.php?shownews=10

[Wild_qwerty]

Oh yea, I have a lot of new weapons effects from FOT too, if you want some of that 'eyecandy'
_________________

[mvBarracuda]

[sztupy]

[mvBarracuda]

[sztupy]

yeah... I should have made a documentation for it... but no use, bcs. IOEdB5 will be a bit user friendlier
_________________

[Wild_qwerty]

SO after reading the news release on the Ianout site. Is beta 5.0 actually the completed version of the engine?

So in other words would it be good enough to make a real mod on?
_________________

[sztupy]

I don't think there will be ever a really completed version Beta 5 will be the first usable version of the series... after it there are some things to consider including, like multiplayer, OpenGL support, and other things, but these won't change that B5 will be usable as a stand-alone engine for mods.

And we'll try doing the upcoming betas, so they would be backward-compatible.


The best would be to wait for B4.9 and see whether it is good enough for a mod. B4.9 will support mostly everything FO2 has supported.
_________________

[Chronus]

Multiplayer is a must-have, strongest point to making IO.
OpenGL can come later it's plenty fast on new machines any way.
_________________
A single death is a tragedy; a million deaths is a statistic. - Joseph Stalin

[mvBarracuda]

[dude_obj]

[mvBarracuda]

[dude_obj]

Another idea re performance is IO overhead by having verbose text in configuration files. Just an idea here but ... you could preserve the existing configuration formats, but make it so you run a utility that reads the text files and converts them into a binary format. Or the engine could do that conversion when it starts. Binary format means less disk IO overhead, and you're going to be doing lots of reads of configuration files. And I assume there is not only disk IO but some CPU overhead in parsing, which could be reduced using binary reads.
_________________

[sztupy]

There are two main performance issues in B4. First the whole screen gets redrawn every frame. I included some minor optimisations (without it it wouldn't be playable), but not that much. Fallout das the redrawing only if the screen changes. And this would really improve performance, but I'm just too lazy to work on this... And btw. don't forget that IO is 16 (or 32 bit) which means 2 (4) times more data to move and store in the memory

The second issue was the text configuration. Yes dude_obj was right B4 reads those configuration files EVERY TIME it needs something from them... There is a very minor buffering (tis means the last 50 request is sotred in the memory, so if there are 51 requests in one game field, major performance issues wil occur). B5 loads as much data into the memory as possible (in binary format of course). This means higher memory usage, but faster game.
_________________

[dude_obj]

So using this proto as an example ....

<?xml version="1.0"?>
<proto name="00000000" type="Ian">
<text yousee="Ian" lookat="Ian" ondead="Ian!" ondeadlook="Ez te vagy"/>
<unarmed hand1="100000" hand2="100001"/>
<desc ability="1001001101">
<onuse type="0">
<direction x="0" y="0"/>
<script2>
Mode.LootBox()
</script2>
</onuse>
</desc>
<events>
</events>
</proto>

You have 60 bytes to read and you have CPU cycles in parsing data between the XML tags. The format is nice for the human, not so nice for the engine. Strip the XML out, convert the numerical text to binary, and how many bytes do you have?

You can probably reduce IO significantly here by making a "commit" program. The game developer must run commit whenever he makes a change to the XML. The commit parses the XML and makes binary format protos. The commit could be smart enough to check date stamps to only parse files that have changed since last commit. Total disk IO goes down in the engine, and so does CPU cycles in much simpler parsing, since you can brute force the binary proto to match data field sizes in the engine (read right into a C struct). Add a smarter/bigger caching scheme and that should resolve the IO issues at least.

Regarding graphics, this is SDL now right? Are you using double buffering? What I'm reading says that double buffering slows things down and can be turned off with the SDL_DOUBLEBUF flag. I don't know if that makes the video degrade too much but it might be worth trying if you haven't tried it already.

EDIT: here's a wild idea ... how about a commit program that can parse the proto data into IanOut OR FO2 format? I have manually edited approx 2000 FO2 protos by hand and I'm a little tired of that routine. And it gets worse I find I have to hex edit more and more to add things not supported by the official mapper (new calibers, sound codes etc). If we can agree on XML proto formats that satisfy both IanOut and FO2, I might be convinced to write a commit parser (write to binary) utility that works with both engines. We then have a clear migration path for most game objects. Also I have spent hundreds of hours reordering FO2 protos because they are a nasty mess. Add to that a new set of 540 critters (FO1/FO2/FOT) and 75 new weapons for IanOut.

Mapping is another issue I'd like to discuss later. The official mapper can save as text. Actually its a command that converts ALL maps to text, it takes a long time but it works. There might be a way to make a converter that reads those saved text files and convert to an IanOut compatible format. The mapper is quirky for sure but it works.
_________________

[mvBarracuda]

[mvBarracuda]

I talked to Sztupy @ sunday and we spoke about your ideas dude_obj

This week they write 2 tests so he's got a lot of stress But he promised me that he'll have the time at the end of the week to reply to your post and clear things up, so please be patient; we haven't forgotten your ideas

[dude_obj]

[sztupy]

So let's see... I don't like the idea of the commit program. The only use it would have is that every developer would have to run it after each change. No, if I would be a modder I would be too lazy to do this. XML format is easier to read for a hman eye, it's easier to edit, and it doesn't take up that much CPU to load and convert it when loading a map file (loading an FRM animation takes more time, than loading an XML file, and there are usually more graphics on a map, than scripts)

About FO2 and IO conversions. When I started the project the fallout modding was in a really early stages. There wasn't even an undat program. That's why I started the project, because I never thought that modding this game would be easy. Since then a lot of tools has been made, but I don't really know anything about them. This way I don't know anything about FO2 modding, about the format Fallout uses, etc. This means also that I don't know anything about the logic of fallout modding, so IanOut will have definitely an alternative logic. This would also mean, that it's possible that there won't be a non-human way to do the conversions. It's maybe possible but I don't know that yet.

About MySQL: I like postgres better But if we would use MySQL DB, than all mods would have to install a MySQL database to their machine. This is OK for lot of people, but not for everyone. Besides copying the content of the database is not as simply as pressing an F5 button in Total commander. This doesn't mean I don't like this idea, it's just that I see more negative aspects than positive. But we could make a converter that creates an MySQL database out from the data files, and after the modifications it creates the appropriate XML files.

And third: IO is script and DLL (.so) driven. This means that nothing will have properties like "caliber", or "strength" or etc. All object will have a lot of variables that can be modified, and the scripts will decide about their use. For modders this would only mean that there should be a global database about these variables, so if someone want's to add a new thing, it shouldn't cause a conflict with someone elses modification.
_________________

[dude_obj]