CarWorks - a different approach to car making

[Cas]

That's right. You can also recur to Stressed for that and you avoid exportation via OBJ (which can't pass wheel and collision data).

And I forgot to mention that, when you generate debris, the primitives are selected randomly from the ones found in the model (car1), so you if you later try the explosion and you don't like how it looks, you can go back to CarWorks and re-generate the debris, some other primitives will be picked and so you do until you like the ones chosen.

[Ryoma]

I try the paint but I was limited to 5. I did Crtl+P but after 5, I choose color but it never changed (work well for the first five).

For the débris, the color stay the same as the first paint job.

[Cas]

I've been trying to make a car from scratch with CarWorks to really test the issues myself and I have found bugs. However, to my surprise, they are not the same bugs you describe. I had tested many on the features on ready-made cars and mostly not on cars made from scratch. I had not found bugs generating debris or with paint jobs.

Now, with a car made from zero, I am experiencing the following problems that I want to address:

• The default collision information generated leads to a crash as soon as the game starts
• No matter what I do, no debris is generated
• Looking inside the 3D shape file, there are some blocks filled with bytes at FFh, yet the car does load normally both in Stunts and CarWorks

Because of the fact that I'm not getting debris, I can't test your second issue. I'll try that with a ready-made car and try to figure out what happens. The first issue doesn't seem to happen to me or maybe I'm not understanding it correctly. Remember that Ctrl+P adds a new paint job. By default, for a car created from scratch, 7 paint jobs are produced.

[Ryoma]

Cas could you try on my XM ?

[Daniel3D]

I try the paint but I was limited to 5. I did Crtl+P but after 5, I choose color but it never changed (work well for the first five).

For the débris, the color stay the same as the first paint job.

Maybe the color is generated when the paint job is copied (and thus the first color) but doesn't follow when changed ion the copy.

[Ryoma]

again this limit to 5. Look my shape.

[afullo]

I have troubles compiling for libtinfo.so5 (Ubuntu 18.04). These are the error messages (I suppressed the paths of the files for shortness):

Code Select Expand

targalib.bi(53) error 58: Type mismatch, at parameter 5 of IMAGEINFO() in 'ImageInfo img2, , , , dpitch, dstart'
targalib.bi(79) error 58: Type mismatch, at parameter 5 of IMAGEINFO() in 'ImageInfo img2, , , , dpitch, dstart'
targalib.bi(107) error 58: Type mismatch, at parameter 5 of IMAGEINFO() in 'ImageInfo img2, , , , dpitch, dstart'
targalib.bi(137) error 58: Type mismatch, at parameter 5 of IMAGEINFO() in 'ImageInfo img2, , , , dpitch, dstart'
targalib.bi(245) error 58: Type mismatch, at parameter 5 of IMAGEINFO() in 'ImageInfo iptr, , , , linelength, imagestart'
FBImage.bi(60) error 58: Type mismatch, at parameter 5 of IMAGEINFO() in 'imageinfo imgDst,,,,dpitch,d'

I have just installed FBC 1.08.1 on this PC, but along with all its references as listed in the readme.
Maybe I can try again on the PC from which I successfully compiled the previous versions...

EDIT: also from the usual PC it fails:

Code Select Expand

carworks.c: In function 'EDIT3D':
carworks.c:9934:31: warning: self-comparison always evaluates to false [-Wtautological-compare]
   TMP$531$2 = (int64)-(EXBM$1 != EXBM$1);
                               ^~
ld: impossibile trovare -lFBImage-64-static

The warning is not fatal, but what is -lFBImage-64-static, which the compiler does not manage to find?

[Cas]

Ryoma:
I looked at both shapes and they look very good!  The first one is complete. For the second one, only the showroom model is defined and I do notice that paint jobs 5 and 6 are identical. I understand that, what you are trying to do is convert paint job 5 to some other colour. This will not work directly because 5 is a custom colour (not present in original Stunts cars). To create a new colour for paint job 6, you must start from an original colour. Try this:

1 - You will have to delete current paint job 6 first. Select paint job 6 and press Ctrl+O. This will effectively remove it
2 - Now you'll have to select a paint job from which to recreate paint job 6. Choose one that's available in original cars, such as paint job 1 (blue)
3 - While on paint job 1, press Ctrl+P to create a new paint job 6. You'll see the new paint job is now blue
4 - Select paint job 6 and press Enter while pointing at the 3D view port. You'll be able to pick a new colour for it
5 - The colour will change to the one you pick because CarWorks recognises the original colours for the transform

I know this is not intuitive and I do plan on fixing this so that all paint jobs can be transformed

Daniel3D:
When a paint job is copied, the colour of the paint job you're standing on is the one that's copied to the new paint job, regardless of whether it's custom or not. It's not super intuitive, because Ctrl+C and Ctrl+V allow for copying and pasting shapes from a model to another (with all of its paint jobs included) while Ctrl+O and Ctrl+P remove and copy paint jobs from within every shape. You can imagine this as two actions that work on a table; on applies vertically and the other one applies horizontally. While this works, I would like to make this function in a more intuitive way in the future.

Afullo:
I know exactly why you get these two errors (and one warning)... well, not quite for the warning, but at least, I know what's going on.

First, the problem about type mismatch is that there's a parameter that's defined as Integer, but this type changes width depending of whether we're working on 32 bit or 64 bit. Unfortunately, the graphics library FBGFX used by FreeBasic, is made in C and C's int does not switch between 32 bit and 64 bit in the same way as BASIC's integer. To make this work well, I would have to replace this integer with a LongInt for 64 bit, but now this means you'll have to switch it to Long for 32 bits. Very annoying. You won't be able to compile it for 32 bit without touching that. I can go to the source and see if I can use some #defines, so that this no longer happens. Because this library wasn't included before, there was no problem. You can just avoid the library when compiling for 32 bit and that should solve the problem.

Second, the error that says that you can't find the FBImage library. This is because, with this last version, I've incorporated a 3rd party library to add compatibility with PNG and Jpeg, primarily. This is the reason why I don't like using 3rd party libraries: they create dependencies and compilation problems unless everything is provided with the source, which makes the package enormous. This can be solved in two ways. One is I send you the binaries for this library and you'll be able to compile it. Another is to compile without the library: to do this, you go the the source code and comment the line that says #define __USE_SOIL__. Then native support for PNG and Jpeg will be dropped, but the program will compile. There is the third, crazy option, of you compiling the source of the SOIL library with C, but that is a lot of extra work that a regular user shouldn't have to do to get a simple program running on their computer.

Third, the warning. At some point of the development, this strange warning started coming up. I wasn't able to find which line of my code causes it to appear, but what I know is that compilation works anyway and the program can run without a problem. It's a bug in the FreeBasic compiler. No other explanation possible.

So... I think I'll send you those library binaries... ha, ha

EDIT: I've been researching. Not a bug in FB. What happens is that the width has changed to fixed in more recent versions of FB, which explains why the problem didn't occur before. I'll be changing the sources accordingly. You'll still need the library binaries, though.

[afullo]

I know exactly why you get these two errors (and one warning)... well, not quite for the warning, but at least, I know what's going on.

First, the problem about type mismatch is that there's a parameter that's defined as Integer, but this type changes width depending of whether we're working on 32 bit or 64 bit. Unfortunately, the graphics library FBGFX used by FreeBasic, is made in C and C's int does not switch between 32 bit and 64 bit in the same way as BASIC's integer. To make this work well, I replace this integer with a LongInt for 64 bit, but now this means you'll have to switch it to Long for 32 bits. Very annoying. You won't be able to compile it for 32 bit without touching that. I can go to the source and see if I can use some #defines, so that this no longer happens. What I don't know is why we didn't have this problem before.

Hmm, I intended to compile for 64 bit also on the machine on which I freshly installed FBC (it is the PC that had 32 bit Ubuntu until Easter, but then the hard drive had a failure and on the new one I installed 64 bit Ubuntu).
Maybe, in fact, I tried inadvertently to compile for 32 bit, so I have to briefly check for options or parameters.

Second, the error that says that you can't find the FBImage library. This is because, with this last version, I've incorporated a 3rd party library to add compatibility with PNG and Jpeg, primarily. This is the reason why I don't like using 3rd party libraries: they create dependencies and compilation problems unless everything is provided with the source, which makes the package enormous. This can be solved in two ways. One is I send you the binaries for this library and you'll be able to compile it. Another is to compile without the library: to do this, you go the the source code and comment the line that says #define __USE_SOIL__. Then native support for PNG and Jpeg will be dropped, but the program will compile. There is the third, crazy option, of you compiling the source of the SOIL library with C, but that is a lot of extra work that a regular user shouldn't have to do to get a simple program running on their computer. So... I think I'll send you those library binaries... ha, ha

Ok, I think too it is the better idea, thanks in advance.

Third, the warning. At some point of the development, this strange warning started coming up. I wasn't able to find which line of my code causes it to appear, but what I know is that compilation works anyway and the program can run without a problem. It's a bug in the FreeBasic compiler. No other explanation possible.

It seems to be evaluated whether EXBM$1 differs from itself, which is of course contradictory. Since before the minus sign an int64 is present, we can suppose that the "false" is casted as a zero, so the result is simply that integer.
A comparison different from a tautological one would likely result in the possibility that the integer has to be diminished by 1, since a "true" is probably casted as an one.

[Cas]

In FreeBasic, any non-zero integer value is taken for "true", but if you want to produce "true" as an integer, what you get is -1. For clarity:

Code Select Expand


If 0 Then Print "This will never be printed"
If 1 Then Print "This will be printed"
If -1 Then Print "This will be printed too"
If 5 Then Print "And this, of course, will be printed as well"

Print "This number is a zero: ";
Print (5 = 1)
Print "This number is a negative one: ";
Print (5 = 5)

Using a -1 for "true" allows using bitwise logic operators for Boolean logic. This is the way it worked in QuickBasic. FreeBasic does the same thing, but also has a Boolean data type and strictly Boolean procedural logic by means of AndAlso and OrElse, which only check the left hand side operand if the other one is irrelevant.

I'm posting the static binaries for the Linux version of the library here. As I mentioned in my edit of the previous post, after some research, I found that it's not a bug in FB, that type mismatch. What happens is that old versions of FB used Integer for ImageInfo, while new ones have a 32 bit and 64 bit version that can be used together. Therefore, it's better to define everything at fixed width.

[afullo]

Ok, thanks, I attach the (64-bit) executable.

As I mentioned in my edit of the previous post, after some research, I found that it's not a bug in FB, that type mismatch. What happens is that old versions of FB used Integer for ImageInfo, while new ones have a 32 bit and 64 bit version that can be used together. Therefore, it's better to define everything at fixed width.

So, this is why FBC 1.07.x did not exhibit that error, while FBC 1.08.x does.

[Cas]

New update! - CarWorks 1.0.4 is out

New features include:

• Support for saving PNG files via FBImage/SOIL/stb_image and Jpeg via ImageMagick
• Dash manager 2X/3X zoom toggle on all operation modes, including editing functions, by pressing Q
• The file manager can now browse full cars instead of individual car files. This can be toggled with a button and with Ctrl+C at the file list screen
• Added Car Project file format (".car") that saves all five car models, including auxiliary, and keeps all car information in a single file

Also, a bug is supposed to be fixed now: clicking on drive letters in Windows was not working. Now it should work. Can you guys test this?

As always, bug reports and suggestions are more than welcome. I haven't had a lot of time lately, which is why it took me so long to post an update to these important features and bug fixes and there's a lot that's still pending. I'll update the thread header as well.

[afullo]

Here is the 64-bit .so5 executable; the click on drive letters in Windows seems still not to work, but a second opinion could be of further use.

[KyLiE]

Also, a bug is supposed to be fixed now: clicking on drive letters in Windows was not working. Now it should work. Can you guys test this?

Clicking on drive letters in Windows works for me, however it takes you to the last selected directory on that drive.  I would expect it to take you to the root directory of the drive like Bliss does.

[Cas]

Thanks, Afullo. Just updated the package with the new binary. I'm curious that you do continue to experience problems with the drives while KyLiE doesn't have that problem. Could you guys re-check to make sure or to see why the difference?

And KyLiE. I don't know why I didn't use the same scheme from Bliss. So, you expected it to work like Bliss because you are used to seeing that in Bliss or do you actually think it'd be better the way Bliss does it?  Because now that I think about it, I'm really not sure what's more adequate. Keeping a "current directory" on each drive is the standard in DOS, as I remember it and probably, it is in Windows nowadays. I don't know. Anyway, the important thing is that you guys feel it's comfortable.