Quote from: KyLiE on March 23, 2022, 07:05:12 PM
This is a great car! :) You've done an excellent job on the visuals and performance parameters. However, I noticed an issue with the crash sprite. The further the car is from the camera, the more incorrectly the crash sprite appears. It's not a huge issue, but I thought I would mention it in case anyone knows what causes it.
I've thought i found the cause if this. but it seems a bit more complex.
I run zakstunts with game exe. (the execompiled version of stunts that is used for the reverse engineering) so no modifications in the code.
In this version i have normal explosions with the original cars but the Ferrari Indy by Ryoma, the supercart by overdrive and this car (those if picked for testing) all have this explosion bug.
EDIT: Just checked the original uncracked game, and it is exactly the same there. It seems to be something shared with all custom cars.
That issue with the explosion graphics does happen with a lot of custom cars (I remember first noticing it with the McLaren MP4/4), though not all of them (the Skyline is a counterexample). I have no idea about why it happens, either...
(This is a very nice car, by the way! I know it's a different chassis-engine combo, but anyway the colour schemes bring me back to Indianopolis 500: The Simulation :))
About the crash sprite bug, I'm only guessing, but could it be that something such as the car-car collision radius, the distance between the wheels or perhaps between the first eight vertices (bounding box) have to be an exact multiple of some number? This would explain why moving the car away from the camera increases the error, because the division gets more and more imprecise.
Quote from: Cas on March 29, 2022, 04:14:48 AM
could it be that something such as the car-car collision radius, the distance between the wheels
I guess they are the same as Porsche March so I would discard them.
Quote from: Cas on March 29, 2022, 04:14:48 AM
perhaps between the first eight vertices (bounding box) have to be an exact multiple of some number?
I don't understand why the first eight vertices? :D You mean the first 4 pairs of bytes?
What I did and I'm sure Zapped also did with McLaren Honda is to use as base to model car1 was to use car0 from Porsche March.
Quote from: alanrotoi on March 29, 2022, 04:51:45 AM
What I did and I'm sure Zapped also did with McLaren Honda is to use as base to model car1 was to use car0 from Porsche March.
Maybe there is a connection in using car0 as car1.
Can't imagine what or how though.
Maybe models imported into stressed as object VS models made from scratch?
Quote from: Daniel3D on March 29, 2022, 07:01:02 AM
Quote from: alanrotoi on March 29, 2022, 04:51:45 AM
What I did and I'm sure Zapped also did with McLaren Honda is to use as base to model car1 was to use car0 from Porsche March.
Maybe there is a connection in using car0 as car1.
Can't imagine what or how though.
Maybe models imported into stressed as object VS models made from scratch?
I replicated the bug with the porsche INDY.
If you save an original P3S as an 3SH in stressed you can edit the file in Carworks.
If you then copy Car0 to Car1 in Carworks and safe, you have the bug.
There is something in Car0 different from Car1 in the original cars.
So any car with an scaled edit of a Car0 used as model for Car1 will have the bug I think.
Wow well done! We are getting closer. So does it works with all cars or only Porsche March? The only explanation would be there is a polygon forgotten in a high distance from the car, then the game thinks the car has a bigger size?
The strange thing is that I did not edit the model.
Just copy and paste.
Carworks does automatic resizing, but I it would be the same as manual resizing.
If it export car0 in stressed and directly try to load it as car1, stressed crashes. (Might be a scale error)
Could the problem be the polygon number 13? It is useless but it's there.
No it isn't :D I checked in Lola and isn't there so... I don't know.
Thinking from this idea about car0 and car1... if you look ingame when racing starts you'll see Mclaren and Lola a bit forward at the start comparing with the Indy. I thought it's because this car0 to car1 copy.
Quote from: alanrotoi on March 29, 2022, 03:58:35 PM
No it isn't :D I checked in Lola and isn't there so... I don't know.
Thinking from this idea about car0 and car1... if you look ingame when racing starts you'll see Mclaren and Lola a bit forward at the start comparing with the Indy. I thought it's because this car0 to car1 copy.
Well, if you copy 0 to 1 you can see the model of the pmin move backwards a bit. So you are correct in that regard.
Well spotted, Daniel! I still think it has to do with the scaling. My reasoning is this:
Say the guys at DSI knew that they would have scaling problems when rendering the shapes on track, then they made sure to use proper factors for the car1 model, but this was not necessary for car0, so they didn't fix those. Now, when you copy car0 on top of car1, you usually do get the bug because car0 simply wasn't made taking this bug into account, but car1 was. Our custom cars have all their shapes made without this scaling bug into account, so we always get the bug.
I think Stunts is trying to produce a crash sprite that looks correct for each car shape, so it attempts to scale it and even to shit it according to where the car centre is and how big it is in each of its dimensions (or maybe just one dimension, could be too). To do this, it's readying something from the model that could be used to have an idea of how big the car is. This could be the distance between the front wheels and the back wheels (and perhaps also the distance between the left wheels and the right wheels for the other dimension, if it does take two different dimensions into account) or it could be the size of the bounding box (first eight vertices in every shape).
Now, the collision radius and the collision box (which I hadn't mentioned) would've been suspects too, but now, Daniël's tests are convincing me that they are not the culprit because these values are stored in the CAR*.RES file and are only used for car1. It has to be something that's present in every shape. So, again, I'd say, look at these things:
- Distance between wheels (in each dimension)
- Size of the bounding box (first eight vertices)
- Maybe distance between the non-bounding vertices that are the farthest away from each other in each dimension, but I don't think so
Quote from: alanrotoi on March 29, 2022, 03:49:29 PM
Could the problem be the polygon number 13? It is useless but it's there.
It could be something like this. But it would be in car1..
And missing in the Lola (and most other custom cars)
Quote from: Daniel3D on March 30, 2022, 08:52:55 AM
Quote from: alanrotoi on March 29, 2022, 03:49:29 PM
Could the problem be the polygon number 13? It is useless but it's there.
It could be something like this. But it would be in car1..
And missing in the Lola (and most other custom cars)
It's not a vertice or polygon. No relation can be found at least.
It's not in the collision box parameters. That is tested, and they have no influence on this bug.
I can't find anything in culling data,
It's not in the mystery bites.
I checked the source code, but that is very hard to read in this case.
I can identify the animation loop, and references to the scale, location and pitch.
But I can't figure out how..
It seems that this bug is at the moment unsolvableThere may be a clue in the source, but that requires somebody more at home in programming than me.
Part of the code below. 8)
https://bitbucket.org/dreadnaut/restunts/src/aa1e714a66f8f9bd0d78bb1c0c3ab6b69252721d/src/restunts/asmorig/seg012.asm#lines-13556 (https://bitbucket.org/dreadnaut/restunts/src/aa1e714a66f8f9bd0d78bb1c0c3ab6b69252721d/src/restunts/asmorig/seg012.asm#lines-13556)
shape_op_explosion proc far
var_14 = word ptr -20
var_12 = word ptr -18
var_10 = word ptr -16
var_E = word ptr -14
var_C = word ptr -12
var_A = word ptr -10
var_8 = word ptr -8
var_6 = word ptr -6
var_4 = word ptr -4
var_2 = word ptr -2
s = byte ptr 0
r = byte ptr 2
arg_0 = word ptr 6
arg_shapeptr = dword ptr 8
arg_6 = word ptr 12
arg_8 = word ptr 14
push bp
mov bp, sp
sub sp, 16h
push ds
push si
push di
mov ds, word ptr [bp+arg_shapeptr+2]
mov si, word ptr [bp+arg_shapeptr]
mov cx, [bp+arg_6]
mov ax, [si+SHAPE2D.s2d_unk1]
imul [bp+arg_0]
sub cl, ah
sbb ch, dl
mov [bp+var_2], cx
mov cx, [bp+arg_8]
mov ax, [si+SHAPE2D.s2d_unk2]
imul [bp+arg_0]
sub cl, ah
sbb ch, dl
mov [bp+var_4], cx
jmp short loc_3484E
; align 2
db 144
push bp
mov bp, sp
sub sp, 16h
push ds
push si
push di
mov ds, word ptr [bp+arg_shapeptr+2]
mov si, word ptr [bp+arg_shapeptr]
mov ax, [bp+arg_6]
mov [bp+var_2], ax
mov ax, [bp+arg_8]
mov [bp+var_4], ax
jmp short loc_3484E
; align 2
db 144
loc_3482C:
pop di
pop si
pop ds
mov sp, bp
pop bp
retf
push bp
mov bp, sp
sub sp, 16h
push ds
push si
push di
mov ds, word ptr [bp+arg_shapeptr+2]
mov si, word ptr [bp+arg_shapeptr]
mov ax, [si+SHAPE2D.s2d_pos_x]
mov [bp+var_2], ax
mov ax, [si+SHAPE2D.s2d_pos_y]
mov [bp+var_4], ax
loc_3484E:
cmp [bp+arg_0], 2
jb short loc_3482C
cld
mov ax, [si+SHAPE2D.s2d_height]
mul [bp+arg_0]
mov al, ah
mov ah, dl
or ax, ax
jz short loc_3482C
mov [bp+var_8], ax
mov ax, [si+SHAPE2D.s2d_width]
mov [bp+var_A], ax
mul [bp+arg_0]
mov al, ah
mov ah, dl
or ax, ax
jz short loc_3482C
mov [bp+var_6], ax
mov dx, cs:sprite1.sprite_pitch
sub dx, ax
mov [bp+var_C], dx
add si, 10h
mov dx, 1
xor ax, ax
mov [bp+var_12], ax
mov [bp+var_14], ax
div [bp+arg_0]
mov [bp+var_10], ax
mov al, ah
xor ah, ah
shr ax, 1
jz short loc_348A8
add si, ax
mov cx, ax
If only happens to custom cars it is a problem of the edition. It doesn't happen to all the custom cars. At least itnhappens when you use car0 from (at least) Porsche March. Does it happens if you use only stressed or when you resize the model with carworks it appears? Wich cars has this bug?
Most, not all, custom cars have the bug. (Not checked with all cars)
It might be related to scaling, that seems to trigger the bug.
But I can't find a relationship.
Ok, just did a quick test.
I build an entirely new car model in stressed from scratch. (just insert shapes in stressed and manually positioned all vertices)
it took me 23 minutes and made a few mistakes (two wheels were inverted) and it is a simple model.
It's an Eastern car, and it is called "the flying carpet". 8) 8)
I know, it is not much. But it doesn't have the bug..
That was what i wanted to know. . Now, let's see if it can get the bug, and what has changed when it does,.
(I used the PMIN files as filling. I attach the shape file for safe keeping)
Quote from: Daniel3D on March 29, 2022, 11:22:36 AM
If you save an original P3S as an 3SH in stressed you can edit the file in Carworks.
If you then copy Car0 to Car1 in Carworks and safe, you have the bug.
There is something in Car0 different from Car1 in the original cars.
So any car with an scaled edit of a Car0 used as model for Car1 will have the bug I think.
This car0/car1 theory might sound odd at first, but I do feel there's something to it. The car1 of the Skyline, which doesn't have the bug, was made out of the Corvette car1, with the car0 being based on a scaled up car1 rather than the other way around.
I think that you are right. I also tested with moving car1 to car0 and back. That doesn't produce the bug
But I think there is a complexity factor of some sort as well. The best chance I can think of to analyse is the simplest model that gets the bug.
So if anyone has half attempts, tests or failures lying around. Please share them for science 😜
What about a negative height issue of the polygons?
Quote from: alanrotoi on April 03, 2022, 07:37:39 PM
What about a negative height issue of the polygons?
I'm not familiar with that issue. How can I create this?
I mean if a polygon has a negative Y axis (from Stressed point of view) coordinate value. What if this is the origin of the bug?
I'm afraid that I still don't understand what you mean. :(
Can you give me en example?
When you build a car you have to give coordinates to every polygon. I think ground level value in vertical coordinates is 0. Stressed allows you to build polygons under 0 value. Maybe there is something here.
PS: I say vertical coordinates or height because Stressed calls this axis "Y" but the rest of humanity calls it "X" :)
Only blender user's and a few others see X as vertical. Mostly y is used for the vertical axis. As does stunts.
But I don't think that any of the cars I tested with the bug have negative y axis values. I will look into it though.
A negative value could have something to do. If that's the case, it should be in the vertices of wheels, because all cars have all other polygons higher than the wheels. The way to test it is simple (in comprehensive terms): just verify the vertical coordinate of each vertex and check it's equal to or greater than zero.
Since custom cars have been created without thinking about this, I would say that it's a possibility, but I'm surprised that it's more likely for the bug to happen than for it to not happen, so my guess is that this is not the problem, but we definitely should check.
I normally choose a coordinate system that uses Z for the vertical whenever gravity is involved, so maps are (X, Y). This is the coordinate system used in CarWorks and in Blender. The other very commonly used system is the one with Y for the vertical, which is used by Stunts, by the OBJ file format and by Minecraft, to give some examples. I personally don't like that system because I feel that the vertical is not like the other axes when gravity is present. Another reason is that the system with Y going up means that Z goes negative away from the screen, which is not intuitive (unless you use a left-handed system), but as long as there's consistency, every coordinate system is OK really.
Of course. I didn't think about the wheels..
Quote from: Cas on April 05, 2022, 01:22:25 AM
A negative value could have something to do. If that's the case, it should be in the vertices of wheels, because all cars have all other polygons higher than the wheels. The way to test it is simple (in comprehensive terms): just verify the vertical coordinate of each vertex and check it's equal to or greater than zero.
It is not that simple. The wheel vertices ar only on the top of the wheel. So you would need to substract the top y from the bottom y coordinates.
But that is easy to check manually.
It's true. The outer edge can be represented downwards, but most commonly, it's done upwards. It's unlikely for a negative to be present, then. It would have to be a significant design mistake. The distance between the car base (or wheel centre) and the ground is very easy to see.