Our ReVolt Pub

https://vid.me/LvmP

Most of the game's effects stop working on this particular stretch. It behaved the same way in 1.2+wine, which ofc I chalked up as just wine being itself, but RVGL (15.0827a) has the same problems:

- battery/zap auras disappear (ground glow still works, though)
- 'pickup get' animation doesn't play
- shockwave main part doesn't show
- oil slicks phase in and out depending on how you look at them

- problems only seem to occur when driving in that specific direction
- also happens if that direction is faced while inside the house


Also possibly worth noting: in all the videos I've seen of RV the battery/zap auras render a bit outside of the car's body. For me in RVGL, it always draws the effect directly onto the body.
Not sure if it's normal for them to show in the low cam either.

particle excess probably.
i have seen such bugs on random multiplayer matches. (except the oil one)

Abc @ 21 Oct 2015, 09:38 PM wrote: particle excess probably.
i have seen such bugs on random multiplayer matches. (except the oil one)

This is me in single player and edit mode, so I'm the only car on the track. Happens in any mode and with any number of cars.

F9 info reports zero sparks other than those I'm creating myself.

Did it happen in wine 1.2? have you tried actual windows 1.2?
bug might come from porting mistakes.

Abc @ 22 Oct 2015, 02:32 AM wrote:Did it happen in wine 1.2? have you tried actual windows 1.2?
bug might come from porting mistakes.

It did happen in wine v1.2 as well, yes. I said that in the OP, and if you'd be so kind as to actually read it before replying, you'd have noted that I also said why I didn't bother reporting it back then.

However, as you can see the topic name is tagged with [RVGL] and I even detailed the version that I'm using, the number of which does not match any v1.2 versions.

In case it isn't clear enough, that means it's happening in RVGL as well.

Considering your reply to Abc's comment these questions may annoy you but as far as I can tell you didn't really specify these things so here goes:

1) Are you using native Linux RVGL or Wine + Win32 RVGL?

2) Does the same thing happen for you in native Win32 RVGL (if you are able to test it on the same system)?

3) Does it matter which car you use? (you always used the same in the videos/gifs)

4) Have you tried messing around with the settings to see if the issue still occurs (Vsync on/off, window mode on/off, etc)?

Considering the direction of the camera when this issue occurs it might be happening because of the water stream in that garden area being rendered?
Its just a far fetched guess but its the only thing special to this level (that and there are quite a few pickups placed in this whole area, but if that was the cause this issue would occur in other levels as well).

As for the zip/glow effect being shown in low cam (and to some degree it being rendered outside the body), that depends on the car itself so its not really a bug.
Unless you can show a comparison of the same car displaying this effect in a different way in 1.2 of course.

It's not that questions in general bug me, it's just his replies are almost always half-arsed guessing from what I've seen and experienced, which could be avoided by doing something as simple as reading the OP and putting an ounce of thought into it.

1. Native Linux RVGL

2. I haven't booted Windows since January and nor do I plan on sitting through multiple hours' worth of updates. I have a vm set up though, I'll give that a shot

3. happens with any and all cars (same with low cam aura render)

4. not extensively, though it does happen in both vsync on/off and both windowed/fullscreen

Effects work properly when in the grassy area with the stream, even while inside the water, so I don't think that's it. I'm guessing the problem is going to be some seemingly-random thing like that though.

Hardware is a laptop with (in this case) Intel HD 4000 graphics (so nothing special), and same results when running native linux rvgl on the Nvidia card (NVS 5400M).

----
Update on question 2: http://i.imgur.com/ypCwKNo.png
Update 2: copying my linux-native rvgl.ini over fixes nothing. log says it's found, but same error
Update 3: tested rvgl+wine just because, same visual results as OP

Update on question 4: turning down draw distance seems to change the behavior, investigating further
Update 2: not getting anywhere myself, but that's something to look into

umm, rvgl builds require windows txt for strings i think, that might be the cause of the cant find languages. have you verified them in notepad++ or anything that shows you the text type?

Turns out it wants UTF-8 for the file format, and exactly zero of the strings/lang.txt files that come in the download are formatted that way.

I managed to get it running once (enough to make it generate rvgl.ini on its own), but now it crashes every time I launch it, with no relevant info written to the log, so yay wasted effort.
I guess -rgb isn't properly implemented or something? but that's entirely unrelated to the original problem.


----- EDIT:

Ran it on an actual Windows system. Images one, two, and three.

- aura still draws directly onto car
- aura still appears in low cam
- aura still mostly disappears when camera faces that direction, albeit to a lesser degree
- other issues (oil disappearing, shockwave not showing, pickup animation) appear to be gone
- I can never seem to remember the arg that enables windowed mode

Granted it is different hardware (amd card, idk what graphics) so not sure what it's worth.

From your report, the Nhood2 glitch occurs both in rvgl and v1.2+wine. What about native v1.2 on Windows? I mean it could be an original bug (could be an engine limitation with transparent polys). Can you confirm that?

The aura appearing directly on the car (and in low cam) is an intended change in v1.2, from what I remember. Again, checking native v1.2 on Windows could help.

Gotolei @ 23 Oct 2015, 08:31 AM wrote:Turns out it wants UTF-8 for the file format, and exactly zero of the strings/lang.txt files that come in the download are formatted that way.

I managed to get it running once (enough to make it generate rvgl.ini on its own), but now it crashes every time I launch it, with no relevant info written to the log, so yay wasted effort.
I guess -rgb isn't properly implemented or something? but that's entirely unrelated to the original problem.

Hmm the lang files in your screenshot are so old (see the date modified). Make sure you extract all the files from the rvgl zip package, including the latest strings files. Maybe that is also the reason for your crash.
FYI, none of the re-volt versions use UTF-8, not even RVGL. Also, software emulation (with -rgb or -mmx) is not supported by RVGL (it's a DX6 feature, neither OpenGL nor DX8+ have it).

I can never seem to remember the arg that enables windowed mode

In RVGL it is -window or -window width height
In v1.2 it is -window or -window -res width height depth

v1.2 15.0330 on that same W7 system gives the same results as RVGL on W7. If only a single aura is active, it behaves properly. but if multiple auras are active at once* then all but two or three disappear under the conditions. Other effects (oil shockwave etc) seem to work properly at all times.
*while in rvgl on linux and/or wine, only one aura needs to be active to trigger the bug

String files are indeed old, seems when I extracted the files over they didn't replace the existing ones for whatever reason. I'll give that another shot then.
E: still crashing with the newer lang files. it's a vm, quite frankly i'm not expecting much of it
(should have noted that the game doesn't necessarily crash, but the entire vm self-aborts)

Good to hear some of the changes are intended and not bugs, at least.

Gotolei @ 23 Oct 2015, 10:19 AM wrote:v1.2 15.0330 on that same W7 system gives the same results as RVGL on W7. If only a single aura is active, it behaves properly but if multiple auras are active then all but two or three disappear under the conditions. Other effects (oil shockwave etc) seem to work properly at all times.

Looks like when we are facing this direction in NHood2 we are reaching the transparent polys limit. An original engine limitation that requires more investigation.
The electro and battery aura (what we call the "car env effect") are actually transparent polys not env polys, but we're used to calling it env (it's shorter ). Re-Volt engine is very limited when it comes to transparent polys (we can only handle 1500 trans polys on the screen at a time). Back in 2011-2012 I planned some deep changes to re-volt's transparency rendering, including the use of multi-texturing wherever possible. But as we were not sure about keeping DirectX6 I decided to postpone it. I hope to take a refreshed look into it with RVGL.
Again, an eventual shader based implementation would take care of these limitations and also improve compatibility with drivers.

Gotolei wrote:String files are indeed old, seems when I extracted the files over they didn't replace the existing ones for whatever reason. I'll give that another shot then.
E: still crashing with the newer lang files. it's a vm, quite frankly i'm not expecting much of it
(should have noted that the game doesn't necessarily crash, but the entire vm aborts itself)

Ah ok, maybe the vm doesn't support OpenGL emulation very well...

Gotolei wrote:Good to hear some of the changes are intended and not bugs, at least.

I've pinpointed the modification, it's this one from Alpha 11.1215:

v1.2 changelog wrote:Optimized car env effects (electro, battery) for performance.

We no longer create an "env skin" over the car, we just draw the env, I mean transparent polys, directly on the car. This improves the loading time (for high poly cars) and avoids glitches in case the car normals are messed up (because we need proper normals to compute the env skin).

Transparent poly limit would explain the difference between installs. I recall there being a mod either here or on RVL that adds a lot of 32-bit textures and model transparency to the stock tracks, and sure enough a number of the models and textures that I have in my main install are datestamped 2012 or later.


Looking forward to a day when "car.png" instead of "car.bmp" can be commonplace