Our ReVolt Pub

i was talking about tracks only.
here is my try, check it in the game please, i didnt test it,
download bmp here

That looks like a Nearest Neighbour Re-Size. They work quite good blended with the Smooth option.

@human
sorry, a bad shorcut in my mind made me think you were talking about car...

So, I agree that when doubling the texture size like you did (i.e. no bilinear or bicubic stuff), there is no information loss.
But, it seems that doing that way, the ending filtering is less effective than with unmodified textures, as adamodell tried to explain:

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.

I need to make some screenshots for each case to really compare.

hmm, ok, i still dont fully understand the whole texture problem, but thats fine, i never did i hope you guys can achieve something in this field.

yes urne, i just used the nearest neighbour option, based on what i thought the problem was, that sounded like a good idea.

hmm, ok, i still dont fully understand the whole texture problem,

Me too. No, I'm joking , but it really is a bit confusing.
So, to sum up the current state:

The patch works well, but it needs 512x512 pixels textures to render nice.

The texture problem only appears when you use it with 256x256 texture, that is to say all the current levels and cars textures (stock and custom)!

So what is needed?
Probably a complete redraw of all textures to 512x512.
And that could be done by hand (a lot of work in perspective , but perhaps feasible for stock textures), or may be an automated way, but that is not that easy.

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.

I took a very quick look at the source, and what I'm saying may be wrong but... I don't see RV doing anything what you're saying about ANDing the pixels. It all seems to be going through Windows APIs. At least when the texture is loaded. Or is what you're talking about the ANDing done during runtime, while racing?

Anyway, when loading a texture these seem to be the relevant Windows API calls:

LoadImage
StretchBlt

So the damage done may be at Windows API level already? There's other calls to Windows API too, but I have no knowledge of Windows API so I may have missed something that could be relevant.

If there's any parameter you need me to check on one of these calls I can take a look... but I don't have much time to analyze the code.

It's good to have info from someone looking at the source.
Ok, nothing very surprisingly in the fact that you don't find anything is the revolt source about ANDing, as I can't find anything in the revolt disassembly too. It is just something that I guessed by drawing some test textures and looking at the result in the game.

I've already looked around the LoadImage and StretchBlt calls and I believe that the ANDing happens in the StretchBlt call. So, from API docs:

The StretchBlt function copies a bitmap from a source rectangle into a destination rectangle, stretching or compressing the bitmap to fit the dimensions of the destination rectangle, if necessary. Windows stretches or compresses the bitmap according to the stretching mode currently set in the destination device context.

but I can't found nothing about the 'the stretching mode currently set in the destination device context'

In the meantime, it's mainly curiosity, as I think not much can be done with that (especially if the ANDing is really in the API call)

jigebren @ Dec 14 2009, 12:26 AM wrote: It's good to have info from someone looking at the source.
Ok, nothing very surprisingly in the fact that you don't find anything is the revolt source about ANDing, as I can't find anything in the revolt disassembly too. It is just something that I guessed by drawing some test textures and looking at the result in the game.

I've already looked around the LoadImage and StretchBlt calls and I believe that the ANDing happens in the StretchBlt call. So, from API docs:

The StretchBlt function copies a bitmap from a source rectangle into a destination rectangle, stretching or compressing the bitmap to fit the dimensions of the destination rectangle, if necessary. Windows stretches or compresses the bitmap according to the stretching mode currently set in the destination device context.

but I can't found nothing about the 'the stretching mode currently set in the destination device context'

In the meantime, it's mainly curiosity, as I think not much can be done with that (especially if the ANDing is really in the API call)

As far as I can guess, the destination is created using CreateSurface API call.

It receives this kind of parameters:

dwFlags = DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH | DDSD_PIXELFORMAT | DDSD_MIPMAPCOUNT | DDSD_TEXTURESTAGE;
ddsCaps.dwCaps = DDSCAPS_TEXTURE | DDSCAPS_SYSTEMMEMORY | DDSCAPS_MIPMAP | DDSCAPS_COMPLEX;

A big problem, at least for quick googling, is that RV has been done using DirectX 5 (or was it 6), something ancient anyway... there's not much documentation online for such an old version so I have no idea of those flags. Nor of the default flags for those that have not been set.

I've found a few days ago the help file for directX 5 and 6, it could help to investigate.
Reading quickly through it after what you said, I wonder if it could have something to do with stuff like D3DRENDERSTATETYPE or D3DSTATUS...
From directX5 API docs:

The D3DRENDERSTATETYPE enumerated type describes the render state for the D3DOP_STATERENDER opcode. This enumerated type is part of the D3DSTATE structure. The values mentioned in the following descriptions are set in the second member of this structure.

Each value is explained, though I have not found yet something related to AND operation. But perhaps it's not referenced under that name.

I am curious how you implemented 512 x 512 textures. I think that the Arctic Blast mod would be an excellent place to attempt a full test-run. Perhaps we can discuss this in Private Chat or Email?

@zagames
I agree with you about Arctic Blast being a nice place to perform a full test-run.
Collaboration on some point would surely benefits to each other, so we can dream about a Arctic Blast HD mod .
I PMed you my email.

<HS>
Anyway, years ago, I achieved to tweak some stuff about the car shadows (I've lost all information but perhaps can try it again). If your about to change the stock cars, it could help.
<&#092;HS>

im trying to be not offtopic guys, but you just tell me to shut up if i was,

jigebren, are you saying that you have created a patch for the 1027 version which makes it possible to use 10 pieces of 512 bitmaps, and the game runs them fine? if yes, does that mean that we have 4 times more texture space than before?
forget the problems with the 256 textures for a minute, but is the answer yes for the above question?

You're not offtopic at all, but I thought it was clear:

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 the answer to your question is 'yes'.

does that mean that we have 4 times more texture space than before?

Yes, in a sort a way. In fact, it's a question of point of view:
- either you consider that you have a doubled quality
- or you consider that you have 4 times more texture space than before
It's all the same.

well, that is just brilliant! im already happy!
that means i can create revolt512 type tracks, and anyone who wants to race them just needs to patch the exe, correct? (once its tested and proved to be stable)
providing that you make it available for the public...

well i would like to test that beast if possible, if you could send it for test,
my mail is revoltoid@gmail.com

one more question: do you think its possible to have more than 10 bmp textures for a track?

Awesome we have some success!

i will gladly test it for ya. send it over to my email ( zipperrulez@gmail.com )

can i have it too? victor_black_cat@yahoo.com
thx

wow dude its awesome, nice work so far. ill see if i can help you with some resizing, as i dont know any code language.

I want it too please. (mironutz_boy@yahoo.com)
see you soon.

Ok, I think I sent it to everyone...
But for request please use PM (I mean, send me your email by PM), not to pollute the topic and to prevent your email adress from being exposed/sniffed

thanks for it!

human @ Dec 14 2009, 01:44 PM wrote: one more question: do you think its possible to have more than 10 bmp textures for a track?

you may not need to... with the 512x512 bmp resolution, you go from 10 bmps to work with to a ridiculous number like 40, but the only thing is, it wouldn't look any better. You'd just have a lot more stuff...

btw jig, I'd like to test this thing out too, to make sure it works on stone-age systems... just Pm it to me cuz i never check my email anymore

Dave&#045;o&#045;rama @ Dec 15 2009, 10:15 PM wrote:but the only thing is, it wouldn't look any better. You'd just have a lot more stuff...

of course it will look a lot better.

Just to inform you that I'm currently writing a tool to convert the stock 256x256 textures to 512x512. I'm not sure if I will make it available, but at least it would allow me to release all stock resized textures.

To do the job properly, I had to separate the colorkey layer (all the pure black pixels) from the colored layer. I use smooth resizing for the colored layer, and a filter of my own for the colorkey layer (this filter does a smoothing without blurring). Then I merge the two layers.

So, I hope this way will give satisfactory results.

Just be aware that the basic outlines on a brick texture for example, could look rather blurred, compared to a nearest neighbor re-sizement.

jigebren @ Dec 15 2009, 12:05 AM wrote: Ok, I think I sent it to everyone...
But for request please use PM (I mean, send me your email by PM), not to pollute the topic and to prevent your email adress from being exposed/sniffed

yeah sorry i wasnt thinking, anyway i get a lot of spam as it is anyway, so it doesnt really bother me.

"Mike wakes up"
"He thinks about a Hull Breach track with the full complement of texture use"
"Mike is very excited"
Time to plan a new track me thinks mwahahahahahah

Just be aware that the basic outlines on a brick texture for example, could look rather blurred, compared to a nearest neighbor re-sizement.

In fact, using nearest neighbor re-sizement wouldn't be useful in that case, as we would just see bigger pixels than in unmodified revolt (for reasons that have been vaguely exposed previously).
But, as I'm not satisfied from what I get with the smooth filter when sizing-up, I'm trying to implement another filter that would be a better compromise between sharpness and smoothing. But I don't currently know if it will work.

@Skitch2
I would be a great reward for me if my work would give tracks authors (like you) the will to create new good stuffs

Also, I'm waiting from my internet provider to activate my personnal account (they said 1 day, it makes more than 1 week), so I could release my things on it (but you can still ask me by PM/email for the moment).

jigebren @ Dec 20 2009, 12:41 AM wrote: Also, I'm waiting from my internet provider to activate my personnal account (they said 1 day, it makes more than 1 week), so I could release my things on it (but you can still ask me by PM/email for the moment).

Why wait when you can use free sharing sites too? (i.e. : Box.net, Mediafaire, Yola/Synthasite, etc...)

Skitch2 @ Dec 19 2009, 11:13 PM wrote:
Time to plan a new track me thinks mwahahahahahah

you better! haha its been too long

nero @ Dec 25 2009, 05:29 PM wrote:Why wait when you can use free sharing sites too? (i.e. : Box.net, Mediafaire, Yola/Synthasite, etc...)

Don't know. Perhaps because I'm to distrustful .
Anyway, my account was activated, so I will do it in a few days.

jigebren, just let you know that i didnt have time to try the patch out, but as soon as i manage to release my track ill start testing it, im as excited as mike is, i guess he thinks the same about the possibilities of having 512 textures.
keep us updated about the project, thanks.

Thanks human. In fact, I was close to start feeling a bit disapointed about the lack of feddback , but I understand that during christmas time, we all have other things in mind, so it really doesn't matter.

But for the moment, I need feddback from those who have the patch to see if it's working nice.
After that, there will be some other tests to conduce about mipmaping (i.e. the .bmq files).

I will soon try to release some 512x512 resized stock track textures. Resizement is done automatically, and I have to know is the output looks correct.
If it's the case, this tool could be used to resize all the existing custom tracks and cars to 512x512.
(for this tool, I finally use my custom filter for the colorkey layer and a classic bicubic for the color layer, before mixing the result).
So stay tuned...

cool.
i did feel that you may need more feedback, thats why i thought i can reassure you that i am on it, i just didnt have time. having 512 textures is a huge advantage, and competent hands can do wonders wit them. i personally think that there are two obstacles: poli limit and texture limit, if at least one of them is beaten, that opens the way to making more spectacular and enjoyable tracks.

I would like to help testing, but as I use the 0916 patch I might not be much as a help. You are still considering not to make the patch compatible with that version, are you?

urnemanden @ Dec 27 2009, 01:35 PM wrote:I would like to help testing, but as I use the 0916 patch I might not be much as a help. You are still considering not to make the patch compatible with that version, are you?

I was really not excited by the idea of redoing all the same job twice to support the 0916 version. I'm taking a look at it, and if it's not too boring, I'll update the patch to support this version too.

I have just opened my website:

http://jigebren.free.fr/jeux/pc/revolt/index.html

Very sober, isn't it?
Here you can found the lastest version of my patch, and may be one day some other stuffs...

Very nice! Simple, yet has an eye-friendly layout. Do you use software?

Oh, and here is my little addition to the upcomming 512x512 textures for the original graphics. I used the Re-Volt logo from the installation background, but I had large troubles making the text look right. Now it at least looks okay on black background.

urnemanden @ Dec 27 2009, 10:26 PM wrote:Very nice! Simple, yet has an eye-friendly layout. Do you use software?

Thanks. Well, I just use KompoZer which helps me to see the result while I'm elaborating the code, and I do all the formating stuffs using CSS.

By the way, nice job, urne.
The funny thing is that I just discovered this good quality logo this afternoon, when I was installing from the cd to get a 0916 version in order to conduce some tests on this version for the 512 patch.
I've tested your image, and it look a bit nicer than the image I obtain with the auto resizer tool I wrote.

But I think there's one thing we have to care about: using antialiasing on a black backgroud look nice, but as this background will became transparent in the game without transition, perhap antialising should be avoided on the edge. But it's just a detail, as it appears that original revolt creator themselves used antialising...

I tried to optimize the anti-alias your mentioning, but the result makes the letters a bit pixelated in a weird way. What looks best? (above post)

I would suggest simply making new test. It seems so much simpler to overwrite what is there and start from scratch.

urnemanden wrote:I tried to optimize the anti-alias your mentioning, but the result makes the letters a bit pixelated in a weird way. What looks best? (above post)

I'm not sure about what look best. But what to keep in mind is:
The black backgroud will be rendered as total tranparency, but black is an arbitrary choice. We could have choosen pink or yellow as the tranparent colorkey. Thus, using antialising on the edge touching that background doesn't have a lot of sense (I believe). In fact, it will look nice in the game when the backgroud is dark, but it will look ugly if the background is bright...
So, it can look a bit weird without antialising, but anyhow, there is no transparency gradient when rendering in the game.
Perhaps we could try to find an acceptable method. (I suggest something like: try to draw an a grey (rgb[128,128,128]) background with antialiasing ON, then convert the grey background to black just at the end, when exporting image to bmp file. As grey is an average color, it could look acceptable in most conditions).

I would suggest simply making new test. It seems so much simpler to overwrite what is there and start from scratch.

Do you mean, redraw all stock textures from scratch?

For the most part. I'm sure some stuff can be used from the original textures. But text, and other stuff can easily be redrawn.

Also, would it be easy enough to resize the textures, then simply go around and trim off all the 'dark/black' and color it all 0,0,0? For example, resize the texture with the anti-aliasing, then use a tool such as Photoshop's 'select like colors/wand thing' to completely remove all the black/close to black colors then replace it with solid black. It may still need some minor adjustment, but it will probably be easier then most other options.

zagames @ Dec 28 2009, 04:33 PM wrote:For the most part.  I'm sure some stuff can be used from the original textures.  But text, and other stuff can easily be redrawn.

Ok, I agree.

For the second part, if I clearly understand what you mean, I'm not sure it would be possible to find a proper setting for the 'close' value in 'remove all the black/close to black colors'.
What I do for the moment is:
- Separate the colorkey layer (black), resize it with smart smoothing (i.e. without blur or gradient).
- Resize the other color part with bicubic filter, test that it does not create unexpected black pixels.
- Merge the two layers.

It gives something like that (clic on the image for the .bmp file):

Another good news (for urne and maybe some others) is that I've updated my patch to support 0916 version too.
As usual now , you can find it here.

Don't forget to report feedback! Even if all is ok, I need to know.

great news jigebren,
i use 1207 but i know other people who use 0916.
guys, can you please kindly test this bmp, i think its a good try:

Thank you! Also, keep in mind that the stock cars both have a black layer and a white layer as edge (sometimes red). I am going through each of them, currently 8 finished basically.

EDIT: Here is all stock cars with 512x512 textures (untested):

Cars512x512.zip

I didn't realize you had a patch for this already.

Wow! By taking a look at the high trees in JungleVolt you can actually see the leaves on the branch texture!



Thanks for this quite nice patch. Here is a few texture packs I quick-re-sized so Re-Volt looks okay:

512Frontend.zip
512gfx.zip

Oh, and then I updated the JungleVolt textures as there seemed to be a 000-color bug.

jigebren @ Dec 27 2009, 11:16 PM wrote:

urnemanden @ Dec 27 2009, 10:26 PM wrote:Very nice! Simple, yet has an eye-friendly layout. Do you use software?

Thanks. Well, I just use KompoZer which helps me to see the result while I'm elaborating the code, and I do all the formating stuffs using CSS.

By the way, nice job, urne.
The funny thing is that I just discovered this good quality logo this afternoon, when I was installing from the cd to get a 0916 version in order to conduce some tests on this version for the 512 patch.
I've tested your image, and it look a bit nicer than the image I obtain with the auto resizer tool I wrote.

But I think there's one thing we have to care about: using antialiasing on a black backgroud look nice, but as this background will became transparent in the game without transition, perhap antialising should be avoided on the edge. But it's just a detail, as it appears that original revolt creator themselves used antialising...

Me too, I use KompoZer as well. Haha, You're probably the only other person besides me in the community that does. Take a look at my site if you want.

Hmm. At least you actually release your work, unlike *cough* rst *cough cough cough PHLEGM!!*