Raw Binary Image File Format as additional Map format

[paul424]

How about having a Raw Binary blob for storing tiles ? Do you want me to implement that ? That would make level files much more readable ....
Or do you want to store that in tga format , so one can use picture editor ? http://en.wikipedia.org/wiki/.tga Bertram say something

[Danimal]

TGA TGA!!! that would be really easy to use and cool

[Bertram]

Hi

How about having a Raw Binary blob for storing tiles ? Do you want me to implement that ? That would make level files much more readable ....

Yes, for the machine, but not really for us.

The TGA solution sounds smart to me (or even XPM, since it's the perfect half-way between the image and readable array of tiles, but it's up to you), but as long as the spec of each pixel/tile is well defined and not hard to understand for users.
So that even I could do beautiful levels quickly.

Regards,

[paul424]

Here;'s nice tga reader https://code.google.com/p/libimago/source/browse/#hg%2Fsrc , my hand just shaken when I saw it's LGPL .
I must first learn what does it change for our license to incorporate this piece of code ( probably nothing , cause LGPL is GPL compatible ) .

[oln]

I would have thought we are already using a library that can read TGA through Ogre, no need to add an extra one?

[paul424]

People, if we could all have had a habit of backing up our claims by providing url links , we would all spare less time googling together ...
http://www.ogre3d.org/docs/api/1.9/classOgre_1_1Image.html#a75ced161976ffbb4fc1cf63d4b007993

[Bertram]

Hi,

For the record, LGPL is GPL compatible AFAIK. And yes, Ogre should be able to help us about loading images into buffers.

[paul424]

First iter is in branch : paul424-image2map , problem is we don't even have TileType :: room , there are only :

enum TileType
{
nullTileType = 0,
dirt = 1,
gold = 2,
rock = 3,
water = 4,
lava = 5,
//if the last type is changed it must also substitute the type
// referenced in Tile::nextTileType()
claimed = 6
};

Not only that, but what I think the map encoding should be as simple as possible, any idea how we could encode room type and ownership in terms of color ?
Could we use the alpha channel ? Is it accessible in most type of myPainte type editors ? First is thought is to use the players color, and the brightness factor could encode the room type. you can say that is quite unintuitional for the map user. But if we always inprint some additional info label (say 800 x 600 ) which would list all accessible colors in form of table / pallete : like rows : player color , columns room color , then user could use the color pick-uper and draw whatever he wants .

[Bertram]

Ho Paul,

First iter is in branch : paul424-image2map

Cool

problem is we don't even have TileType :: room [...] But if we always inprint some additional info label (say 800 x 600 ) which would list all accessible colors in form of table / pallete : like rows : player color , columns room color , then user could use the color pick-uper and draw whatever he wants .

I do think we shouldn't have to print something additional, but rather have a common standard or if you want have the same additional file for every maps.

Not only that, but what I think the map encoding should be as simple as possible, any idea how we could encode room type and ownership in terms of color ?
Could we use the alpha channel ? Is it accessible in most type of myPainte type editors ? First is thought is to use the players color, and the brightness factor could encode the room type. you can say that is quite unintuitional for the map user.

I agree this would be unintuitive for the user as well. Your above statement made me think about this:
Why not add a second image where only the rooms/traps are listed using the team color? This way, a user could simply edit the file as a second layer on GIMP for instance, and then export each layer as an image, and voilà! What do you think?

I'll have a look at the rest of your code asap. I'm a bit busy/finishing other things atm, sorry.

Regards,

[MCMic]

I don’t see how editing levels as images is a good thing…
There will be a level editor in OD anyway, right?
And if an external tool is needed why not use Tiled (http://www.mapeditor.org/)?

[Danimal]

And then im being told not to rework things because they are not critical... Paul instead of this i would concentrate on the culling code that will allow us to up the poli count on everything. You are spreading too much and risk not finishing anything in a long time.

[paul424]

O_o are there some models which kill down the fps ?
Ok, ok I can get back to culling ...
EDIT : the load function has been also implemented.
EDIT: Well if they were REALLY REALLY critical you would do them right away . But to the point : hte problem is how slowly new models come , and in my ( lamer/ non-blender professional ) (naive ) view the creatures and especially static objects could have been converted in one overnight , but they weren't for the whole year .... How long it would to convert all those models on first list ( in terms of hours work ? ) .

[oln]

There has been a lot of work on new models lately.

[Danimal]

Paul, i have been blunt, but what i want to say is that this is a hobby for all of us, done on our free time, its good that everyone plans new improvements. But if we plan many things and only made them halfway its almost the same as not doing anything. That said you can really work on whatever you want, noone is paying us to do it, noone can really force us; but there is a commom objective, making OD alpha at least enjoyable.
Culling sounds really awesome, we could add free models over 9k polis almost rigth away instead of having to look or retopo for models between 1k -3k polis, on the other hand colour map editing is not a bad idea, but only useful on the very long run when a map can actually be played and won (or lost). Not to mention creatures behaviour oddities like refusing to figth and many other bugs that avoid a fun play, but we at least managed to make excavating around fun.

So to resume, do whatever you want but dont forget that making the game run should come first before any fancy addition. I like both your fancy additions, both are needed, but not rigth now. Im tired of having my pit demon stand around while kobolds easily kill it.

EDIT: Well if they were REALLY REALLY critical you would do them right away . But to the point : hte problem is how slowly new models come , and in my ( lamer/ non-blender professional ) (naive ) view the creatures and especially static objects could have been converted in one overnight , but they weren't for the whole year .... How long it would to convert all those models on first list ( in terms of hours work ? ) .

No model is critical, they can use placeholders and it wont matter at all to run the game, just the person playing can tell the difference between some nice model and a cilinder. The thing about statics objects on list is this, do we really need all of them? No, what use is a watchtower? no creature will ever get on top, a stool? what for!?, some ramdom pillar or healt potion?, snowman seriously?, sadly almost all static objects are useless to us.
Now regarding creatures models, making a new one can take up almost a month to me (im no pro), i can rework already existing models to have fewer polis and better textures, but i can barely animate, thats the reason in looking into motion capture to make a master skeleton for humanoids and that i hadnt converted any model yet, without animations they are totally USELESS.
Making objects for rooms takes me less than a hour, thats the reason im focusing on them, they are easy, fast, look beatiful and improves the overall looks of the game. The work-result ratio is better than creatures models.

But i get your message, "everyone does what he likes".

[paul424]

Well did you tried it at least : ?????????????????? IT does not only sound awesome , but it could be started from game console.

[Danimal]

I cant compile, so i only run the bin Bertram puts out from time to time

[paul424]

I cant compile, so i only run the bin Bertram puts out from time to time

Ha ha ! that's a good one....
Seems you ain't too have much knowledge what's the fuss with the branches all about .
Well what Bertram ships is the compiled version of branch development. My culling algorithm and cmd to start it is there for a long time

[Danimal]

how can i see console? and what are the commands to start it?

[paul424]

http://forum.freegamedev.net/viewtopic.php?f=45&t=4765&p=56756&hilit=starttileculling#p56756

[Bertram]

Hi guys,

Wow, a lot of stuff happened here lately.

I don’t see how editing levels as images is a good thing…
There will be a level editor in OD anyway, right?

Yes, this isn't a big priority, just by the fact it is already working. That's why I'm strongly asking for people to commit stuff somewhere else than in development, so we don't end merging half-finished stuff.
Yet, if Paul can come up with something worthy, there's no point in denying it. The TGA solution makes it a no-brainer to create map out of height maps and so on, making the feature desirable at least to me, even if not a priority, indeed.

And yes, there is an half-finished editor in OD, that we should try to improve little by little.

And now on the code committed so far:
- Please don't change the user behaviour without telling. ok? Could you change the code so that the command in the txt file is case lowered when checked, instead?

{l Code}: {l Select All Code}

                 // Force command to lower case
                 //TODO: later do this only for params[0]
-                std::transform(command.begin(), command.end(), command.begin(), ::tolower);
-                std::transform(params[0].begin(), params[0].end(), params[0].begin(), ::tolower);
+                // std::transform(command.begin(), command.end(), command.begin(), ::tolower);
+                // std::transform(params[0].begin(), params[0].end(), params[0].begin(), ::tolower)

The usual code cleaness comments:
- Broken indentation on the whole change, could you fix that?
- Could you have a look at how you use commas? It seems you add spaces before and after at random. You should add one space after and only one.
- writeGameMapFromTgaFile(const std::string& fileName, GameMap& gameMap) doesn't respect the filename requested, and doesn't return a bool value.
^ You shouldn't inhibit warnings when coding. This would avoid such things.

Regards,

[paul424]

What I could say: the default behaviour in the Unix word is to respect case sensitivness always .
It was quite a puzzle for to get why my new command does not trigger action.
Yeah also agree behaviour should be agreed, so could we follow the tradition that words are always case sensitive ?

The usual code cleaness comments:
- Broken indentation on the whole change, could you fix that?
- Could you have a look at how you use commas? It seems you add spaces before and after at random. You should add one space after and only one.
- writeGameMapFromTgaFile(const std::string& fileName, GameMap& gameMap) doesn't respect the filename requested, and doesn't return a bool value.
^ You shouldn't inhibit warnings when coding. This would avoid such things.

Yeah my bad, I was so taken by idea, that I just wanted to get the first iter of the feature working , so others are pleased with it ( and get the boost of coding's zeal )

[Bertram]

so could we follow the tradition that words are always case sensitive ?

Agreed.