Our ReVolt Pub

I'm new to the forum, so hi everybody,

(as you may notice , english is not my native language, so please forgive...)

I was thinking about making ReVolt use 512x512 pixels textures instead of the current 256x256.
To achieve that, we need to patch the exe, then upgrade the texture to increase the level of details.

Now, I'm pretty sure this can work, but I want to know what you think about the idea. Do you think it is worth the pain, or you don't care?

welcome maestro,
it was definitely worth the pain, however its not been done so far, erm... is it not because its not really possible?

I think it would be possible, we might as well try. Though I doubt many will stop using 256 x 256 textures.

Thanks for your support.
I've been working (hard) on it, and I can tell you that I think it really is possible:
Look at the image below, the '512 Testing' on the wheel.


(hope this will work, it's the fisrt time I use imageshack)

Don't take care of the red shadow below the car, and you can see there is an artifact around the yellow part of the wheel which is due to fast job for redim, but it should be removable.

I was able to launch this texture for the car, and conduced some other tests on the level textures which worked pretty well too...

I'm all in favor of larger texture support. Although in this day and age I wonder if you might as well skip to 1024x1024 if you're going to jump to 512x512. Maybe I'm jumping ahead of myself.

My only real concern would be that cars and tracks would have to specify which version they're designed for, else include multiple versions of the textures and let users specify which they want. Either way, the end result is very clunky.

Might be good for a conversion, like the arctic thing they've got going on the other forum.

Actually jig, we've known for years that you can use 512 x 512 textures. There is just a color distortion. We support this project because we hope it will eliminate the discoloration. The only problem with jumping up to higher res, aeon, is that it will greatly increase file size. You're practically multiplying the amount of texture space by 16 and therefore the file size will be that much larger. As a personal preference, I'd rather be able to load more than 10 texture sheets at 256 x 256.

zagames @ Dec 10 2009, 09:46 PM wrote: I'd rather be able to load more than 10 texture sheets at 256 x 256.

That wouldn't help car repaints any though.

This is new now. Wouldn't be this possible for tracks too?

I wonder if you might as well skip to 1024x1024 if you're going to jump to 512x512

It is possible but i think 512x512 is enough: as zagames said, when you multiply the size of the side by 2 (e.g. from 256x256 to 512x512), the size of the image is multiplied by 4. And for side_size*4, you have image_size*16.

My only real concern would be that cars and tracks would have to specify which version they're designed for, else include multiple versions of the textures and let users specify which they want

Not really possible that way, but the process is: when ReVolt loads a texture, it automatically resizes this texture to the target size.
So if we set this target size to 512 and revolt found an old 256 texture, this texture will be internally resized to 512 (though in this case this is just a little waste of ressource as there will be no magical improvement of the quality).

Actually jig, we've known for years that you can use 512 x 512 textures. There is just a color distortion.

Correct me if I'm wrong, but I think that, as I explain above, yes you can already load a 512 texture, but it will be internally resized so it is used as a 256 texture, not a 512 texture (thus no improvement at all). So it is not just a color distortion, it's a complete resizement.

As a personal preference, I'd rather be able to load more than 10 texture sheets at 256 x 256.

Let me explain why I think it is a better idea to increase the texture size:
If you increase the texture size, you can increase the visual quality of all existing tracks by redrawing their texture. And as a track maker, you dispose of 4 times the place you had before (as the image size is 4 times bigger).
Whereas if we are just able to load more textures, we can't easily update existing tracks, and I'm not sure it is achievable to have 4 times more textures. And moreover:

That wouldn't help car repaints any though.

Right.

Wouldn't be this possible for tracks too?

Yes, it is! At least I believe.


PS: can you tell me how to have stuff like "QUOTE (zagames @ Dec 10 2009, 09:46 PM)" in front of quotes.

just add something like [Q-UOTE=blahblahblah]....[/QUOTE]
write it without dashes ( - ). and remember that if you type there , will appear @

anyway back on topics please

Would the mapping of the stock track meshes be affected
if Revolt loaded 512x512 without Revolt re-sizing them down?
And if you re-sized the stock textures up to 512x512 wouldn't
there be a loss of resolution?
I don't see the point of 512x512 bmps if Revolt
re-sized them down to 256x256 in the game.
But it is worth testing to see if you can get higher
resolution and more space on a bmp for more textures.

An interesting part of RST's Phoenix program
is the use of four extra bmps (S,T, U and V bmps).
Revolt uses these bmps for car textures when 12 CPU
cars are selected for a race (only 8 cars or less can
be used when these bmps are used. It also needs a
modified ASE2W to be used for export.

No, the mapping of the stock tracks won't be affected, nor the mapping of custom track. That's the goal.

If we resize texture to 512x512, they won't be any lost of resolution AFAIK.
But if you just resize the texture without doing any extra-job, it add no quality to the image. So, to really benefit from resizing, it would be better to redraw some texture by hand (like it is done on the HRP for DukeNukem if you know it).

Next, to clarify some points:
With original revolt, if you load a 512x512 texture, it will re-sized it down to 256x256 internally.
But if we patch it to support 512x512 texture, it will really use 512x512. And if a patched revolt find a 256x256 texture, it will resize it to 512x512 internally. In the later case, there is not quality add or loss.

I know RST's Phoenix can use four extra bmps because I've read it somewhere, but sadly, I don't own this tool, so I can't try/use it.
Anyhow, I don't really like this way of doing, because it would prevent a track to be played with >8 cars. And a track created this way won't be usable by an original non-modifed Revolt, whereas a track created with 512x512 texture will remain usable by the original Revolt.
And as I explained before, I think having a more detailled texture is a better solution than having more textures available.

well...
if you would have Phoenix
it is impossible to work for the other
i mean that four workable bmps added will work just for that who uses Phoenix
for the original RV that won't work.

@miromiro
yeah, that's exactly what I meant...

In witch manner will you patch Re-Volt?

you could make the resizing have the reverse effects. making 256x256 automatically resize themselves into 512x512

To patch revolt, I think about creating a little executable that has to be launched in the revolt directory. It will patch directly the 'revolt.exe' file (and create a backup of course). It could also be reversible.

@zipperrulez
I don't understand. Is that a question?
Otherwise I've said it: I believe that with revolt patched, 256x256 textures are internally resized to 512x512, but I think there will be no real increase of quality unless files are edited by hand (by no better quality, I mean no better quality than with usual filter like linear or bilinear...).


By the way, please note that I'm working on 1207 patched Re-Volt version only, and have no plan to conduce the same work on previous versions. Is that an unacceptable issue for some of you?

im a bit confused and hopeful as well, you guys kept a secret or what?
if it is possible to use 512 files why on earth do i have to work with 256 ones?
one of the (many) reasons why im not keen to make trax, is that making trax for revolt means being seriously limited as a 3d modeler and it is a constant retrograding. at least if we could use more (or bigger) textures that was some kind of consolation and compensation. the trax would still be low poli minimal art, but more textures would give the illusion of a more complex world.

No secret , for the moment, it is not possible to use 512x texture, AFAIK... Perhaps Phoenix R3 from RST does it, as it was apparently planned?

But we're talking about something I planned to achieve, i.e. create a patch to allow revolt to use 512x texture.

And I think you can stay hopeful, as if everything keeps going the way it goes, it WILL be possible (not trying to create a voluntary mystery , but I need a little time to achieve that).

So good news and bad news:

The bad news is that 512x512 textures won't be usable by an unmodified revolt.exe, probably because of the way they are resized by revolt. It give something like that:

I forget that I've already seen that in a test, and I now understand what zagames meaned by 'color distortion'. I'd like to figure out exactly why it gives thing like this . But so far I don't know which mode is used by revolt to resize the image.

In the meantime, It's not really a problem, except that it would force people to patch their revolt to use 512x512 textured tracks.

The good news is that a patched revolt can use 512x512 textures on levels also, see below the original market2, with a 256x256 texture (look at the big pixels on the ventilation grid):

and now with a 512x512 texture, look at the (quickly) redrawn grid on the fridge:

See the difference?
(you can notice the door is a little blurred, but it's due to the bilinear resizing I used.)

good luck
that's all i can to say

I believe you need to learn ASM
otherwise, it would be impossible to load 512x512 correctly

RV used the stupid dx engine, works like so:

* load picture
* size it to 256x256
* recopy it (something called opacity map [replace RGB(0,0,0) with transparency)
* wait until request (from prm/w/m loading)

ive been hoping for this forever!, im currently squeezing as much into my car.bmp that im having to lose certain parts, because i want a more hd look, with this i will be able to make cars look amazing XP ahah

edit (ill also be able to put interiors in my cars )

It's a DirectX texture limit.

Recompiling it with this specified higher would be the easiest fix.
Doing it in hex or something? I don't believe that's very possible. Prove me wrong.

@KDL
I know a bit of ASM (but really just enough to do that stuff), otherwise I would never have been able to do that (and would never have tried). How do you imagine I've done so far?
Thanks for the directx info. How do you know that, have you dx knowledge, or did you study the revolt available sources? (I've never tried yet as I have no C++ (or stuff like that) knowledges)
If you can tell more about how the 'opacity map' process is conduced, I'm interested. Is it done by revolt itself, or by a call to the dx engine?

@MOH
yeah, I think it could be really nicer for cars, as we are currently very limited.

@Adamodell
There is no recompiling at all, just an edit of the appropriate values in revolt.exe. That's why our possible actions are very limited.
And you said there is a DirectX texture limit. If you know more about it, I'd be glad if you can explain...

jigebren @ Dec 12 2009, 04:38 PM wrote: @KDL
I know a bit of ASM (but really just enough to do that stuff), otherwise I would never have been able to do that (and would never have tried). How do you imagine I've done so far?
Thanks for the directx info. How do you know that, have you dx knowledge, or did you study the revolt available sources? (I've never tried yet as I have no C++ (or stuff like that) knowledges)
If you can tell more about how the 'opacity map' process is conduced, I'm interested. Is it done by revolt itself, or by a call to the dx engine?

@MOH
yeah, I think it could be really nicer for cars, as we are currently very limited.

@Adamodell
There is no recompiling at all, just an edit of the appropriate values in revolt.exe. That's why our possible actions are very limited.
And you said there is a DirectX texture limit. If you know more about it, I'd be glad if you can explain...

I don't really want to appear smarter than I am. I convert cars and I know little image editing here and there. I have no programming knowledge whatsoever.

My brother told me of the texture limit and how it was probably related to a DirectX command capping it at 256x256, and the garbling of the textures is the game trying to compensate by running the 512x512 AT 256x256, memory and all, is my guess.

The funny thing is that revolt seems to correctly size up a texture when you supply a too little one, but don't seems to correctly size down a too big one. And I can't figure out why...

Now, new images. As an example, I've resized and enhanced a bit the phat slug texture to 512x512 pixels, then loaded it into a patched revolt.
With the original 256x256 texture, we had:


And now with the enhanced 512x512 texture:


Look at the windshield, and the springs...

Your results looks very interesting jigebren. If I sent you some 512x512 textures from JungleVolt, would you then make a test?

I wish I kept my source files for my Callaway. I had the textures in 512x512 for quite some time during the creation of it.

Basically, I believe it's an issue with the amount of memory allowed for textures.

128x128 is less than, so there is no artifact.
512x512 is more than, and the game only allows and understands 256x256, so when it tries to run that 512x512 at 256x256 it's too much "detail" for a 256x256 amount of space to take... okay I'm speaking gibberish and confusing myself at the same time.

I think I'm on to something but I doubt it'll help you.

@urnemanden
No problem. I can do that.
Be careful when resizing if you use color key tranparency (black color pixels). But I think you know that.

@Adamodell
I understand what you mean, indeed, it could be something like this. Not sure it would explain all artifacts, but the idea is good.

I am not re-sizing the textures up, just using the sizing the original sizes down to 512x512. Here is 3 512x512 textures (100% quality):

512JungleVolt.zip

Note: You need JungleVolt installed.

Ok, I think it's now time for alpha testing!
That's done, I've written a patch that will modify the 'revolt.exe' to support 512x512 textures.
If some of you are ready to test it, I can send you the beast.

So urnemanden, you can test it yourself. Isn't it great?

Hey, will it work for any Re-Volt version? Did you take this into consideration?

LOL

I just realized you said 1207.
That's good, I'm a 1207 user.

I'll test.

Yes, it works only on 1207 version. I have no courage to make the same modifications for the other version.
Just to know, is there really an advantage to use the older revolt version?

Adamodell, how can I send you the file, by email? (I have no way to host files for the moment (if someone can does it easily please let me know)).

I only tested it on windows Xp, with administrator privilege. And I don't even know what 'vista' means...

Yes you can e-mail me.
I sent you a pm.

Well, 0916 is preferred by many because people assume it's more stable, and it's still able to play Re-Volt's music.

1207 disables music and introduces a couple bugs for a few, but I can't remember what kind of bugs.

I don't really have problems with 1207.

@Adamodell
Files emailed.

Does anybody can refresh our memory and tell us about the 1207 bugs?

I think all I remember is it being more crash-happy.

I'm not much of a double poster but, I gotta say a few things.

There are definite glitches when telling this game to run at 512x512, at least on my system. I see some filterless upsampling of 256x256 to 512x512, which makes the linear filtering much, much less effective (the game is filtering at the same rate for what is technically a higher res texture), and the HUD and 2D items have a lot of random black.

The trees on Toys in the Hood are obliterated, and about anything that uses pureblack.

Anything running 512x512 looks perfectly fine though.

Maybe you could release this patch with all the textures resized to 512x512. You'd probably still run into problems with that though, too. Then you have the customs running 256x256... and there's just a boatload of problems with this whole thing.

Other games understand any resolution of map. Why must Re-Volt be all or nothing? NFS4 can run anything from 1x1 to a million by a million, so why can't Re-Volt? Bad programming decisions.

It seems when you tell Re-Volt to go to 512x512 the 256x256 support gets really shoddy.

Ok, thanks for the test.

There are definite glitches when telling this game to run at 512x512, at least on my system. I see some filterless upsampling of 256x256 to 512x512, which makes the linear filtering much, much less effective (the game is filtering at the same rate for what is technically a higher res texture), and the HUD and 2D items have a lot of random black.

The trees on Toys in the Hood are obliterated, and about anything that uses pureblack.

I remember I felt surprised that original textures looks more pixelated after applying the patch. I think I guess why it does that, but I'm afraid it's too complicated for me to explain, and I'm still quite confusing myself with it. I believe it as a link with the .bmq texture files, mipmapping, and the way revolt does internal resizing.
Just as a test, you can try to set the texture quality to 'none' in revolt diplay options.

Anything running 512x512 looks perfectly fine though.

At least, it means the patch is working as expected for what it is designed to, 512x512 textures.

Maybe you could release this patch with all the textures resized to 512x512.

I agree this would be a good solution to release a sort of full HD pack, but it means a lot of work to redraw all the original textures.

In fact, the problem in revolt resizing texture is probably due to the color key transparency, as we can't use usual modes to resize this sort of images (the black piexls have to stay pure black, they must not blend with color around).

jigebren @ Dec 13 2009, 03:24 AM wrote: Ok, thanks for the test.

There are definite glitches when telling this game to run at 512x512, at least on my system. I see some filterless upsampling of 256x256 to 512x512, which makes the linear filtering much, much less effective (the game is filtering at the same rate for what is technically a higher res texture), and the HUD and 2D items have a lot of random black.

The trees on Toys in the Hood are obliterated, and about anything that uses pureblack.

I remember I felt surprised that original textures looks more pixelated after applying the patch. I think I guess why it does that, but I'm afraid it's too complicated for me to explain, and I'm still quite confusing myself with it. I believe it as a link with the .bmq texture files, mipmapping, and the way revolt does internal resizing.
Just as a test, you can try to set the texture quality to 'none' in revolt diplay options.

Anything running 512x512 looks perfectly fine though.

At least, it means the patch is working as expected for what it is designed to, 512x512 textures.

Maybe you could release this patch with all the textures resized to 512x512.

I agree this would be a good solution to release a sort of full HD pack, but it means a lot of work to redraw all the original textures.

In fact, the problem in revolt resizing texture is probably due to the color key transparency, as we can't use usual modes to resize this sort of images (the black piexls have to stay pure black, they must not blend with color around).

Well, as I said, the internal resizing doesn't apply any filters, and the filtering that is available won't be as effective on a "higher technical resolution" (it isn't supposed to be as effective... there's more pixels to go around) if that said resolution is the same "real" resolution (it's just a 256 represented as a 512). The filtering is like 4x less effective because mathematically the textures are supposed to be better.

For the pureblack, you could probably dodge up a weird mode that localizes all RGB 000 pixels and makes a new, separate layer of them, and resizes what's left with bicubic filtering, and resize the pureblack layer with nearest neighbor, and remerge.

That'd be hard to script, though. And every bit as confusing to explain.

The "Re-Volt HD" thing is a problem though. Dodgy compatibility with any (which would be all) customs that run at 256x256.

jigebren @ Dec 12 2009, 06:24 PM wrote:

Maybe you could release this patch with all the textures resized to 512x512.

I agree this would be a good solution to release a sort of full HD pack, but it means a lot of work to redraw all the original textures.

Kinda hard to do that with all of the tracks at RVZT.

Maybe a size-up for the mipmaps from 128x128 to 256x256 would do it?

The test results sounds to me quite good, I would like to see how my own 512x512 textures work with it. But I am on Vista and I am using the 1906 patch. Does it even work with Vista or does it still require -sli?

EDIT: I created all textures for JungleVolt in 512x512, download 'em here:

JungleVolt512

not sure about what you guys are exactly saying here about the textures but are you saying that the patched exe would resize the original 256 stock textures to 512, and therefore because of the nature of resizing they would look strange mainly because of the total black areas that would suffer from resizing on their borderlines where they meet other colors and this are gets messed up when being resized?

texture.cpp wrote: TexturePixels = CountTexturePixels(max, 256, 256);


//////////////////////////
// count texture pixels //
//////////////////////////

long CountTexturePixels(long needed, long width, long height)
{
long i, max;
DDSURFACEDESC2 ddsd2;
HRESULT r;
IDirectDrawSurface4 *sourcesurface;
IDirect3DTexture2 *sourcetexture;
IDirectDrawSurface4 *surface[MAX_TEXTURE_TEST];
IDirect3DTexture2 *texture[MAX_TEXTURE_TEST];
etc...

=> that's why all is resized to 256x256

_


and for transparency (opacity) it's directx 6 format (replace rgb(0,0,0) with alpha ) but not so sure until I get it from the sources

KDL @ Dec 13 2009, 02:10 PM wrote:

texture.cpp wrote: TexturePixels = CountTexturePixels(max, 256, 256);


//////////////////////////
// count texture pixels //
//////////////////////////

long CountTexturePixels(long needed, long width, long height)
{
long i, max;
DDSURFACEDESC2 ddsd2;
HRESULT r;
IDirectDrawSurface4 *sourcesurface;
IDirect3DTexture2 *sourcetexture;
IDirectDrawSurface4 *surface[MAX_TEXTURE_TEST];
IDirect3DTexture2 *texture[MAX_TEXTURE_TEST];
etc...

=> that's why all is resized to 256x256

_


and for transparency (opacity) it's directx 6 format (replace rgb(0,0,0) with alpha ) but not so sure until I get it from the sources

So my brother was right, it really is a DX limit.

well, i dont speak mandarin, but anyway, resizing textures with no pixel loss/change is possible, easy to do.

For the pureblack, you could probably dodge up a weird mode that localizes all RGB 000 pixels and makes a new, separate layer of them, and resizes what's left with bicubic filtering, and resize the pureblack layer with nearest neighbor, and remerge.

I roughly see the things the same way. An utility that would does that could be a good solution, but hard to implement for different reasons (at least for me) .

not sure about what you guys are exactly saying here about the textures but are you saying that the patched exe would resize the original 256 stock textures to 512, and therefore because of the nature of resizing they would look strange mainly because of the total black areas that would suffer from resizing on their borderlines where they meet other colors and this are gets messed up when being resized?

It's quite that.

@KDL
If you look into the source, just by curiosity, can you find something about a mode set for resizing textures, or something like that?
In disassembly, I localize the call to the resizing process, but can't found anything about the way it's done.

What I can tell is that it is revolt itself that tests every pixels to set the black ones to be transparent. And this is done after the resizing process. And the resizing is done by a call to the windows API.

And I've intuited something about the weird color due to resizing process:
Usually, when resizing, close pixels are blended together. But here, I think pixels are ANDed together (operation is a logical AND).
That way, any color ANDed with black color (rgb=$00000) will result in black color (I think it's designed as a quick way to preserve the black transparency information). And, for example, if you blend a pure red pixel (rgb=$FF0000) with a pure green one (rgb=$00FF00), it will also result in a black color (because $FF0000 AND $00FF00 = $000000), thus givin a bad transparecy when we expected a sort of brown pixel.

well, i dont speak mandarin, but anyway, resizing textures with no pixel loss/change is possible, easy to do.

I don't think so, because of the black pixels, but prove me I'm wrong...

well, i so want those 512-s that i can resize a stock 256 as an example, just tell me which one do you want to see resized and i will show what i meant and you will tell me if that is better/same/worse than what you thought.

well, i so want those 512-s that i can resize a stock 256 smile.gif as an example, just tell me which one do you want to see resized and i will show what i meant and you will tell me if that is better/same/worse than what you thought.

In fact, it would be better to make an exemple on a level texture, as they contain more black/transparent pixels. For example , the texture 'nhood1e.bmp' from 'Toys in the Hood' would be a good choice as it has the texture used for the trees.
For a car texture, artifacts due to resizing and transparency are less visible. But if you really prefer working on a car, perhaps you can try on the 'Dust Mite'.
I you want the 512 patch to test the result, PM me your email so I can send it to you.