Our ReVolt Pub

Just to inform you that another patch is perhaps pending.

After Killer wheels was complaining about the increasing size of textures files needed by my 512 patch for revolt, I tried to find a solution.
I dreamed about being able to use png texture in revolt, as I thougt png would be a nice format for that purpose.

And after some dirty hacking in revolt, I was able to load a .png texture file in revolt (I said 'dirty' because I have not sufficient knowledges to assure that all memory/object are properly released, stuff like that, but I think it's ok).

So now, I can load a full level with png textures, and revolt seems to work fine with it.

Moreover, revolt can still uses a bmp file when a png texture is not found.

Great, isn't it?

Indeed! PNG textures don't lose their quality, unlike bitmaps. Although most modeling programs work best with bitmaps, PNG is a great substitute. Hope to see more progress, and keep up the good work.

chriselston @ Dec 30 2009, 08:15 PM wrote: Indeed! PNG textures don't lose their quality, unlike bitmaps. Although most modeling programs work best with bitmaps, PNG is a great substitute. Hope to see more progress, and keep up the good work.

What the heck are you saying??? I've never seen that a 24 bits bitmap lose its quality except for 256 colours and above BMPs.

I guess that changing to PNG wont change anything except for filesize.

It depends on when the texture was made from. Is what I am implying.

Are we talking about 512 x 512 png's?

Sure, as Cat said, there is no quality loss with bitmap (at least with 24bits), so it is not intended to change anything but the filesize.

For example, for 'market1' level, total 512x512 textures filesize goes from 8.25MB to 2.65MB (divide size by ~3), which is pretty cool.
In fact, it is quite as small as original 256 x 256 bmp textures (2.06MB). I hope killer wheels will apreciate.

Are we talking about 512 x 512 png's?

Yes, 512 x 512 png's seem to work like a charm, and I belive it's also the case for 256x256.

jigebren @ Dec 30 2009, 11:53 PM wrote: Just to inform you that another patch is perhaps pending.

After Killer wheels was complaining about the increasing size of textures files needed by my 512 patch for revolt, I tried to find a solution.
I dreamed about being able to use png texture in revolt, as I thougt png would be a nice format for that purpose.

And after some dirty hacking in revolt, I was able to load a .png texture file in revolt (I said 'dirty' because I have not sufficient knowledges to assure that all memory/object are properly released, stuff like that, but I think it's ok).

So now, I can load a full level with png textures, and revolt seems to work fine with it.

Moreover, revolt can still uses a bmp file when a png texture is not found.

Great, isn't it?

I had this idea a long time ago, but I have no knowledge or means to do it. I was crazy enough to do a png2bmp converter inside the folder and batch files to convert for me when picking different car colors.


PNGs, especially optimized PNGs, of textures in Re-Volt can lead to massive decreases in size. Do it.

Impressive work!

.png is a lossless compression of bitmap (24-bits) with alpha additions [up to 48-bits, 32-bits color type is the most used].

however; Re-Volt doesn't support alpha blending in textures (aka transparency, dx6...) so usually, it's going to be translated as pure black rgb(0,0,0).

In this case, leaving a warning to the people to do not save their pngs but bmps so that they wouldn't lose their work then after they compress it to .png if they want to

_

so I believe by asm calls, the program translate the png to bmp, don't you think it require some memory and time?

Hey, that's great news!

I also figured out how to avoid the overshoot that your mentioning is happening when you are re-sizing with the bicubic parameter (bilinear aswell). Here is a comparison of at_homea.bmp:

Bicubic Re-sizement, black color layer (included "triple6's" decoration) re-sized using Nearest Neighbour:


Manual shape-divided re-sizement using "Smooth" parameter:


On the PDN forums I've asked to the smooth option (here).

EDIT: Just thought I would share the rest of the manually re-sized bmps. You can find it on this list: urnemanden.com/dload/512

Happy new year to you all, guys!
Sorry I'm a bit tired today , thus I will be short.

Bad news for the moment, I have a big problem:
If I complete 'market1' and chose restart race without going back to frontend, there is a big mess in the car and trolley textures.
That's why I said dirty hacking...

For now, I haven't got a clue why it does that, so I really don't know if I will be able to fix that.
If anybody have solid knowledges about PE file format (editing the import/export tables), I need help, because it could perhaps be linked to that.

Apparently, there is not a lot of PE experts over here . Doesn't matter... I'm trying to document myself about that, but I think I will have times achieving a correct result.

By the way, a half bad/half good news:
It seems that the texture bug I found is not directly linked with the modification I made to support .png, as I was able to reproduce this bug without this modification. Perhaps it is due to 512patch, or another thing, I don't know for now. Needs more test, but I believe I can't get the bug with an unmodified 1207 revolt.

To make the texture bug appear (if someone wants to test on his system, perhaps with/without 512patch):
I set the race to 1 lap (just to be quicker).
I launch 'market1' level and I complete the race.
When the race is done, I choose 'restart race'.
> here my car texture and the trolley texture gone wrong.

Sometime I need to complete the track more than once to get this bug.
If I go to the frontend and launch the level again, the bug disappear. It's just when I use 'restart race' after a completed race.

A little news four you , but a big for me

To give Revolt the ability to read .png files, I'm trying to use a supplementary .dll file.
But to force revolt to launch this .dll the way I want (i.e. without changing the exe filesize, stuff like that), I was required to write a little utility to modify the import table.

I have to admit it was one of the toughest thing I've ever done as far as computer is concerned. I you take a look on the PE format documentation, I'm sure you will understand why...
But now, it seems to work properly enough (on my system), so I hope I will be able to make something good with that.

I still don't know where the bug about which I was talking before come from, but I'm increasingly sure it's not linked to the .png loading but to something else.
So I would be pleased if some of you can try to run 'market1' level as I explain on the post above, just to be sure...

I tried this out on 512patch 0.4, but didn't get any bugs similar to yours. I drove using 12 cars and with the resolution 1280x1024x32.

jigebren wrote:In fact, it is quite as small as original 256 x 256 bmp textures (2.06MB). I hope killer wheels will apreciate.

Wow, it's like this topic have been created just because of me..





Well, I'm not going to "complain" anymore, though I still have a little question :


Will all creations have to be converted to 512*512 png's files ? Or is there a way to allow your patch doing this automatically ?

I think the second one is possible !


So here's my question : why not making your patch load internally resized images files instead of modifying every single creation's bitmaps ?

I mean that it's probably possible to make the patch detect the image size, so if it found a 256*256 bitmap file then it makes a 512*512 one (no matter wich format) and store it in memory only while the game is active/the level is played.. or whatever.


Maybe it's too complicated for such a patch... huh ? That was my only 2 cents.



Anyway, this png patch is really really interesting ! Good luck

urnemanden wrote:I tried this out on 512patch 0.4, but didn't get any bugs similar to yours. I drove using 12 cars and with the resolution 1280x1024x32.

Sounds good. Thanks for the test, urne. This sort of bug can be linked to such a lot of things (software, drivers, hardware, who knows...) that it's hard to find the cause. Would be nice if other people can try too.

Killer Wheels wrote:Wow, it's like this topic have been created just because of me.. tongue.gif

In a sort of way, perhaps it's your "complain" that started it all .
I was thinking of png textures before, but I probably thought it would be too hard to implement.

So here's my question : why not making your patch load internally resized images files instead of modifying every single creation's bitmaps ?

Good question, I was thinking about this, but I believe I won't do it.
For some reasons, it would force to mix all the patches (512 & png). Moreover, a good texture resizing job is quite long to perform, and it will delay the loading of files in revolt. For now, I prefer to let this job to an external tool.
If one day I release a tool to resize all the revolt textures, it could support png. But don't count on it for now, as this tool would be so long to write...

Anyway, this png patch is really really interesting ! Good luck

Thanks. I hope it will work nice enough for me to release it one day...

jigebren @ Jan 5 2010, 08:09 PM wrote: If one day I release a tool to resize all the revolt textures, it could support png. But don't count on it for now, as this tool would be so long to write...

Why? You could just resize the BMP with whatever algorithms you use, and then use one of the many free libraries or programs that can convert a BMP file to PNG file?

arto @ Jan 5 2010, 09:32 PM wrote:

jigebren @ Jan 5 2010, 08:09 PM wrote: If one day I release a tool to resize all the revolt textures, it could support png. But don't count on it for now, as this tool would be so long to write...

Why? You could just resize the BMP with whatever algorithms you use, and then use one of the many free libraries or programs that can convert a BMP file to PNG file?

It's not that simple.
1st. We can't just resize the bmp (due to the black pixels transparency). You can find more about it in the patch512 topic.
2nd. I had to etablish the list of files to resize (some bmp are resized, some bmp doesn't need to be resized).
3rd. I have to take in account the bmq (and perhaps in the future, the number of mipmaps).
4th. The programming language I use (Purebasic) support png, but the compression rate is very low compare to an image utility (like XnView). I'm not sure there is a better library for it. Perhaps with an external dll.
5th. making a rough utility for me is simple. But making it in a way that it can be release is a lot harder. Moreover, it will need a GUI. Not too complicated, but that's boring me.
6th. I'm far from an experimented programmer.
7th. Other stuff I might be forgotten...

If the 512 textures is in .PNG format, the track makers could make the track double-compatible. It just requires that the 256x256 BMQ's is in "BMP" format, so the normal Re-Volt will be able to show the textures with no trouble. Then you also can use a third mipmap level in the 512patch (128x128 BMQ's - like the normal Re-Volt).

Anyways, I would love to test it when you may have an alpha version ready (;

urnemanden @ Jan 23 2010, 12:46 PM wrote:If the 512 textures is in .PNG format, the track makers could make the track double-compatible. It just requires that the 256x256 BMQ's is in "BMP" format, so the normal Re-Volt will be able to show the textures with no trouble. Then you also can use a third mipmap level in the 512patch (128x128 BMQ's - like the normal Re-Volt).

Anyways, I would love to test it when you may have an alpha version ready (;

Not 100% sure about that, but it's possible nevertheless.

Thanks for the test proposition, urne. But as I'm working 24/24hour and 7/7day on a project I'm late on, I have no free time for revolt developement currently.
As for now I think I will put together all my patches in one tool, you have to wait for this to be released. Perhaps in a few days (or weeks)...

Wow! If I can get my little paws on this I think I would be inspired enough me to make a track.

Do we get alpha transparency with the png's too?

antimorph @ Feb 21 2010, 03:03 PM wrote:Do we get alpha transparency with the png's too? 

Unfortunately, no.
I had this secret hope too when I began working on this part, but after some reading, it seems that transparent textures are way more tough to implement in directx than textures with just aplha transparency. It would probably involve to much changes to be feasible just by patching the exe file, and I have not enough experience/knowledge in all this directx stuff to know where to start from.

Well it's still great to be thinking in terms of 512x512. Just for the record, I tried several times long ago to get some kind of handle on the texture space issue and failed utterly each time, I'm beginning to read 'gigabrain' when I see 'jigebren'. I'd love to see how this fix was implemented.

Gaining expertise with DirectX is not a road that I would choose to travel today given any choice about it, so that issue of variable opacity via alpha seems to be one for the new engine.

antimorph @ Feb 22 2010, 01:46 AM wrote:I'm beginning to read 'gigabrain' when I see 'jigebren'.

I think that when you'll be more aware of the subject, you will moderate your admiration. Anyhow, the pun was good, I'm still laughing... I'm myself quite proud of these patches, because I began with a very few knowledges, but for a real computer geek, it would have been a child's play for sure.

I'd love to see how this fix was implemented.

I don't really know what I can show you. And explaining this in english would take me hours. Do you know how to use a debugger like Olly?

Gaining expertise with DirectX is not a road that I would choose to travel today given any choice about it, so that issue of variable opacity via alpha seems to be one for the new engine.

Maybe. I'm quite lost when it comes to directx stuff. Too bad, because being able to use some new function (eg. D3DXCreateTextureFromFileExA) in place of older revolt code could have help, but as you said, I think it's good to let such things for the new engine.

Will this be released within the WolfR4 or will you update the 512patch to be compatible with png textures?

urnemanden @ Mar 1 2010, 03:46 PM wrote:Will this be released within the WolfR4 or will you update the 512patch to be compatible with png textures?

I don't know yet. I'm still not sure I will include in WolfR4 things that can't be patched in memory but have to be written in the binary file to work (like png support).
About the png implemetation, I left it a bit aside because it's quite a heavy patch. I have to modify the import/export section of re-volt (the section where used .dll are referenced), and this section is not designed to be edited at all.
I had to write a tool dedicated to this task only, and by using some trick, I can add a new import to the section without modifying the file size.

Maybe I could use another way than modifying import/export section, but I don't know how.

I could release a patch just to add the png support (at least in its current beta state), but for now all my efforts are concentrated on WolfR4...

I'm totally okay with that. It won't affect my track projects much further than having to convert the bmp's to png if you were going to work further on this, so I think it's a good idea to at least temporarily limit what you are currently working on, a bit. Just in 1 week you did huge advantages to WolfR4, by taking a look at all the activity on ORP - I am so glad!

I'm sorry, what it the benefit of using .png instead of .bmp?

hilaire9 @ Mar 1 2010, 06:58 PM wrote:I'm sorry, what it the benefit of using .png instead of .bmp?

One single in this case: the file size.
(as unfortunately we can't use the png transparency).

Because when you use 512x512 texture with the 512 patch, the filesize of the texture is multiplied by 4 (going from 192KB to 768KB), and some were complaning about it, so I was thinking about adding PNG support in revolt, to keep texture files quite as little as before.

ok,..er..uh...(I had a thought here, but it is gone)...wait!
ok, a 512x512 BMP is 768 KB, a 512x512 PNG is 131 KB, so...
(hil fixes a drink of diet coke and vodka)...wait!
so you map a track with 512x512 BMPs and convert them to PNGs?
(hil does not think ASE Tools gives a rat's bottom (Manmountain please replace my bad word here to: 'bottom') about PNGs)
(hil is confused)..wait!
I...uh, I forgot my question. MF!
I await the first track made with this patch, then maybe after
that I can suss this out.
Good Night and Good Luck! Wait!