Stunts Forum

Stunts - the Game => Stunts Related Programs => Topic started by: Cas on December 10, 2020, 11:14:46 PM

Title: CarWorks - a different approach to car making
Post by: Cas on December 10, 2020, 11:14:46 PM
CarWorks

Current version: 1.0.4
Last release: 23 September 2021
Project site: http://www.raceforkicks.com/projects/carworks.html (http://www.raceforkicks.com/projects/carworks.html)

Original presentation:

Hi!  I think I should make a thread about the project I'm working on right now. It's nothing too big, but it may be of interest, so here it goes. So far, in this preliminary stage, I've called it CarWorks. Its purpose is to aid in car making, but it's very different from Stressed (and of course, not nearly as developed) and they could be used together. In other words, when it's finished, you will be able to make a car either with Stressed alone or with CarWorks alone, but much more comfortably, with both together.

CarWorks puts emphasis on the interaction with 3D shape editing tools like Blender or Anim8or. It's a simple program that's capable of loading and saving car files as well as OBJ files. When interacting with OBJ files, it takes special measures to preserve the surface materials. This allows the car maker to use Blender, for instance, specifying the car materials in the program (Blender) so that, on export, the OBJ file will have everything it needs to be converted into a car shape. That's the idea, because in practice, so far, a few touches still need to be made.

Another idea I've implemented in CarWorks is auto-generation of information that normally has to be rebuilt from scratch. For example, it can automatically generate all desired paint jobs starting from the original model. You just specify the general hue for a paint job and all shades are automatically created. Same way, CarWorks can load a full-size car shape and scale it for car0, car1 and car2, so you can have a working car pretty quickly. This, of course, means the sacrifice of having a too high-poly shape for car1 and car2, but with modern computers, that shouldn't be a problem. CarWorks as of today, does not do anything with culling. It's all activated: you can see every polygon from every direction (although they're 1-sided by default). If there's a need of a change, it can be made later with a tool like Stressed.

I'll be posting it not far into the future.... but any opinions or suggestions are welcome! :)
EDIT:
The CarWorks+Dash Manager project can also be found at www.raceforkicks.com/projects/carworks.html (http://www.raceforkicks.com/projects/carworks.html)
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on December 11, 2020, 10:36:40 PM
CarWorks puts emphasis on the interaction with 3D shape editing tools like Blender or Anim8or.

Can you make a option to fix wheels?
I'm used to work with XSI (a bit on the heavy side for merely modeling) but when I export back to stressed the wheels are all messed up.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on December 12, 2020, 12:43:11 AM
Quote from: Daniel3D
Can you make a option to fix wheels?
That one's already done, my friend! :)

There is one detail I still have to adjust about that, but it pretty much does the thing. You first load an existing car shape (3SH) of your choice, from which you'll borrow the wheels, then you load an OBJ without wheels on top and you go to "adjust wheels" to place them in the correct position. It is not necessary, but you can also centre the wheels and the car so that the central point of all wheels (or the first four wheels if it has more) is at the centre of the car. This has some positive implications, but some cars don't do it and they still work fine. Alright, I better compile what I have so far so that you can try it.

If you're using a GNU/Linux 64 bit or if you can download FreeBasic, I can post the GNU 64 bit binary and the source code much more frequently than the Windows binary (for whose compilation, I need to get to another computer currently).

Here I'm including the first snapshot!  It's very rudimentary, but it works. It's made from scratch in just a few days.
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on December 12, 2020, 08:17:12 AM
I'm impressed...
Now I can finish my improved showroom version of the truck.
(It may take a while do to lack of time)
Title: Re: CarWorks - a different approach to car making
Post by: Cas on December 17, 2020, 03:52:47 AM
I made a few changes. From now on, the snapshots will be uploaded at the top of this thread (in the first post).

Not all of the following features are already compiled so they may not be present in the snapshot but:


Issues:
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on December 23, 2020, 02:51:06 PM
I've been working a bit with CarWorks. And it looks promising.
But i have some problems using it, mainly because i don't understand it.
The wheel setup part is great, nicely visual and works wonderfully.

But i loaded the alternative Obj but it seems to big
(in the wheel adjustment part because that seems the only graphical part),
but i can't figure out how to scale it.

I know it is in active development, but can you give us some info on how to use the features that are ready?

Title: Re: CarWorks - a different approach to car making
Post by: Cas on December 23, 2020, 08:09:23 PM
Yes, CarWorks definitely is in the experimental phase. It will end up suffering a complete rewriting, I tell you for sure, and will have a graphical interface, more comfortable to use.

About scaling. CarWorks is currently tuned to take OBJs as if 1 = 1 meter. That is, when you create your OBJ files, they should be in that scale so that cars will be proportional to other Stunts cars. With this, CarWorks scales the model twice: 1:200 for real-life to car0, and again 1:20 for car0 to car1 and car2. I'm sure car2 is not supposed to be the same scale as car1, but as it's not horrible, I've left it that way for now.

Because the current version of CarWorks cannot produce wheels, you have to first choose a car whose wheels more or less look well with your model. No problem with moving the wheels, though. All this will be improved.

Right now, I'm at a stop with the main part of CarWorks (the one I published here) because I'm working on the new part, that aids in dash set up. Once that one works well, I'll publish it and it will be two separate programs at first. Then, I'll work in putting everything together and making it look nicer and user-friendly.
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on December 23, 2020, 08:51:32 PM
Since I'm working on the starting line truck, getting the wheels is simple (start with the original)
Then load the modified Obj (which was never scaled) but it still looks blown up..

Will need to do some testing...

Thanks for making it.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on December 23, 2020, 11:51:11 PM
Glad that I can be of help :)  Yes, the original shape I assume will have the dimensions of the car1 shape for regular cars. The current CarWorks is hard-wired to scale the OBJs up 200 times first for the car0 and then down 20 times for the car1 and car2. This is done with floating point vertices, so it shouldn't break your model, but it's true, if you have the original vertex coordinates, you'll need to scale it down 200 / 20 = 10 times in your 3D editor to properly match what CarWorks will take. You can just try with a copy so your original model remains the same in case you don't like the result and maybe later on I can make a fix to allow direct import of default scales.

Have you been working on the interior too?  I think I'll soon finish with that part and it'll probably be of help to you!
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on December 24, 2020, 01:21:56 AM
I still looking for a good image of a dashboard from the right time.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on December 27, 2020, 02:54:35 AM
So here it is!  The first working snapshot of the other part of CarWorks. For now, I've called it Dash Manager. You'll find it not very elegant, but at least, more comfortable to use than CarWorks and I think it will be more useful right now because while Stressed and CarWorks overlap in about 40% of their possibilities, Stressed only overlaps with Dash Manager in about 10% and there is no other program so far that can do what Dash Manager does. Take a look at it, guys.

So here's what it is about:


What it's missing:
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on December 30, 2020, 02:06:52 PM
Ehmm,
I tried the dashboard thingie... and ..

I can't get it to work..

I can load a file and then if I hit a key it just loads a dashboard picture with every key press until they are all loaded. Don't know what to do.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on December 30, 2020, 08:29:37 PM
It's been some time since I posted it and I've made some changes already. I probably should update it. Anyway, I tested it before posting it. I wonder if it's just that the program isn't very clear in its options.

Normally, you run the program and you get an empty screen and on the right, the menu. If I remember well, the version I posted still did not allow to load a whole car. Do you have a menu option for file management there?  If you don't, I better post the new version today. So, if you do have a file management option, you just go to that one and press C to load a whole car. The car files should be in the same directory as the program for now. Then you hit ESC to go back to the main menu and you can "drive" the car with the first option.

In case you don't have this, what you can do is go to "images". With PgUp/PgDn, you can select which of the items you want to work on. By default, the dashboard is selected. So you hit Enter and you give a car ID or file name. The files should be in the same directory as the program. It will only load that item from the car files. This way, you can, if you want, load different items from different cars. It only reads unpacked car files and BMP files. The use of the shortcut keys described in the menu is paramount. There are no easily visible mouse options yet. The mouse does respond, but I've left interface for the last instance. So... I'll be uploading again soon!

EDIT: Adding the updated version of Dash Manager to the first post
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on February 10, 2021, 07:42:10 AM
Thanks ! Two greats programmes which help me a lot. 3 weeks before, I had never made a car.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on March 08, 2021, 09:05:29 PM
OK. Just like I did with the engine, I've uploaded CarWorks and Dash Manager to www.raceforkicks.com. You'll find the link on the main page. But as you know, these two tools are experimental and incomplete and my idea is to make one big good thing out of them eventually. Seeing that they have been seeing some use, I propose that you guys give me any suggestions you have. Especially, if you're creating or editing cars and need a feature implemented or fixed, say it here so I can go and pinpoint the thing.
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on March 08, 2021, 09:08:23 PM
Yes, something that allow to change the dimensions of the car with differents ratios on X,Y and Z.

And adapt the wheelbase at the position of the wheels.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on March 09, 2021, 03:30:29 AM
Yes, something that allow to change the dimensions of the car with differents ratios on X,Y and Z.
Oh!  I never thought that could be useful, but certainly! :)

And adapt the wheelbase at the position of the wheels.
Do you mean like to make the wheel positions that are in the RES file match the actual positions in the 3SH?
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on March 09, 2021, 06:35:12 AM
Yes differents ratio for each axis will be helpful to correct quickly a bad proportion of the car. I have to work again on the Mythos because the width is toi short. And maybe Duplode on the Skyline...

Yes for the wheelbase as said before : the 3sh give the wheelbase and the hitbox of the car.
Title: Re: CarWorks - a different approach to car making
Post by: Duplode on March 10, 2021, 07:57:08 AM
Yes differents ratio for each axis will be helpful to correct quickly a bad proportion of the car. I have to work again on the Mythos because the width is toi short. And maybe Duplode on the Skyline...

Note that the aspect ratio issues only affect the y axis. The Skyline car1, for instance, has 104 length and 40 width, which matches the real car proportions. If I left in a mistake, it is only in the height. (By that way, just in case: make sure to have aspect=true in the [render] section of the DOSBox configuration.)
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on March 11, 2021, 08:49:21 PM
Another issue with differents ratio : it affects the dimensions of the wheels, I had to update Shamal, Mythos and 641 consequently.
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on March 22, 2021, 09:10:22 AM
Another improvement for Dash manager :

When we use some mask (inm1 &3 , ins1 & 3 and even whl1 & 3), we use differents size and coordonate for bitmap.

And dashman apply only the values of ins2 and whl3.

Maybe in the F2 menu, we could ne modify this.

What about if like the Vector, the wheels is to the right limit of the screen, seems the dot are limited to 256 in X position...(I understand something during writting this)
Title: Re: CarWorks - a different approach to car making
Post by: Cas on March 22, 2021, 11:19:39 PM
The INS/INMs all being at the same coordinate is an issue I should indeed fix. I have to make a lot of rewriting, though, but yes. About the 256 value limit for the X for the DOT and the instrument curves, there's nothing we can do. That's stored as a byte and it's impossible to make it go any further.
Title: Re: CarWorks - a different approach to car making
Post by: Zapper on May 01, 2021, 06:45:01 PM
Hi,

I've used dashman recently to fix speedometer coordinates and I guess that it whould be an aid improvement if next to the point number, it could indicate the correspondent value of MPH (point # x 2.5MPH) and RPM as well (point # x 128RPM).


(Reference wiki.stunts.hu Car_parameters Speedometer_needle_movement (http://wiki.stunts.hu/index.php?title=Car_parameters#Speedometer_needle_movement))
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 01, 2021, 07:26:14 PM
Thank you for the feedback, Zapper!  In fact, I wasn't sure about the proportion when I made it. I'll make sure to include that on the next one. As a matter of fact, the CarWorks and Dash Manager I've uploaded here are alpha versions and I'm currently working on the first actual version of the program, CarWorks 1.0, which will be beta at the beginning, but will be what it's supposed to be. It already does some things. Dash Manager will actually become a part of CarWorks 1.0. I'll try to make this version available as soon as I can and I'll make sure to add an indicator for the RPM and MPH that are represented by the clocks!
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 03, 2021, 04:03:15 PM
Alright, I've posted the first snapshot of what will be CarWorks 1.0 in the project site at http://www.raceforkicks.com/projects/carworks.html (http://www.raceforkicks.com/projects/carworks.html). The alpha version (CarWorks 0.1) is still available because the new one, while looking much better and having some additional features, still can't do a couple of things that the old one can (namely, align the car wheels, for instance). There is still a lot to add, but most of the functionality of CarWorks 0.1 is covered already. You'll have to keep using the old DM for now, but I'll soon start implementing it in CarWorks 1.0 as well.

This new version includes:
- Completely comfortable parameter edition, including car name and showroom information, torque curve marks and all
- Ability to load 3SH, OBJ and RES files and save 3SH and RES (OBJ will soon be available for saving too)
- Four-view shape management. No shape editing so far, but you can cycle models with M and paint jobs with P
- Add and remove paint jobs with CTRL+P and CTRL+O. Change paint job colour by pressing Enter on the 3D view
- Auto-shade with CTRL+A. Good for imported OBJ files. Then you can change the colour easily
- Auto-set wheels and collision information with CTRL+B
- Copy one model to another with CTRL+C and CTRL+V

Try it out!
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on May 03, 2021, 05:19:59 PM
Thanks...but actually I stall. I have New idea for à New car. I become lazy.

Edit : I give a quick look, I like the module physical parameters
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 06, 2021, 04:00:09 AM
Alright. I've updated CarWorks 1.0. I think I've reach the point at which all the functionality in CarWorks 0.1 is already available in CarWorks 1.0. It also has many more features, even though it's still unfinished. At this point, while it needs some grooming, I'm pretty confident that you can completely work with CarWorks 1.0 + Dash Manager 0.1 without needing CarWorks 0.1 at all. However, because of the potential of bugs, I still provide the alpha version at the project site as well as the new one.

I have included a "manual" in the zip file with the key shortcuts (which are abundant in the 3D section of the program). You will notice that you can easily ruin your work with just a key combination  ::) I've made sure that all potentially damaging functions require you to press CTRL plus something, so always think twice before pressing the other key if you're holding CTRL. Of course, this all happens in memory, so you can just relax if you've saved your project already.

Some of the newest features added are:

Some known and reported bugs:

As always, you can get CarWorks 1.0 from http://www.raceforkicks.com/projects/carworks.html (http://www.raceforkicks.com/projects/carworks.html)
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 10, 2021, 12:42:14 AM
I'm now working on the Dash Manager part of CarWorks 1.0 and I'm having problems. Since I'm being a lot more careful with this project than with the old CarWorks 0.1 and Dash Manager 0.1, many issues have become apparent, but not enough to easily solve them. One thing has to do with the coordinates of ins1, ins3, inm1 and inm3. These four dash items provide X and Y screen coordinates that do not match anything. At first, it looks like they should be relative to the coordinates of ins2, but not really. I can see that there are slight deviations, which explains why there were problems with the old version. KyLiE has also been telling me that something similar happens with the location of the gear box. I reckon maybe Ryoma and Zapper can shed some light on this, as they are the most experienced ones in car making. If you guys can give me a hint, I'll appreciate it:

How do you calculate the correct  instrument image coordinates from the VSH based data?

I'll keep on researching. Maybe the "unknown" words and bytes have something to do with this.
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on May 10, 2021, 07:15:11 AM
In fact, Every time I tried to understand ins1 and cie, I failed.

So I tried to not use them. And if I need, I made the sames dimensions as ins2. And after, I modify lightly the x and y values in stressed. I always failed the first time...
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on May 10, 2021, 08:56:51 AM
As far as i know ins1 is a free floting layer.
The only restriction i believe there is is that ins2 has to fit on or in ins1.
Title: Re: CarWorks - a different approach to car making
Post by: Zapper on May 10, 2021, 02:09:53 PM
I follow these considerations when creating STDA*. files:

- The image resource "ins2" should have a certain WxH that results in a integer value when divised by 8, for example:
    on Jaguar JR9 "ins2" has 48 pixels width and 34 pixels height:
         48x34=1632 -> 1632/8=204
    the result 204 has no decimal value, so it should be ok.
    I also use this rule on "whl1-3".

- The image resources "ins1", "ins3", and their associated alpha masks "inm1" and "inm3", have the same width and height dimentions has "ins2". In this case they all have to use 0,0 (x,y) starting coordinates since they are all referenced by "ins2" starting coordinates  (wiki (http://wiki.stunts.hu/index.php?title=Car_files#Dashboard_static_parts_.28stda.2A.pvs.29)).
    If "ins1" and "ins3" ("inm1", "inm3" respectively) have smaller images than "ins2", they can be placed on other starting coodinates, but they are all relative to "ins2" (check STDAFGTO.3SH example), and the rendered image cannot overlap "ins2" image area.

There are other considerations that have not been fully clarified. It turns out that when I edit these image resources to make a perfect rendering in the context of CGA or EGA game setup, there is some misalignment rendering "ins*" and "whl*" that I think it has relation with the width x height pixel proportions. (check for example Caterham Super 7 JPE (http://forum.stunts.hu/index.php?action=dlattach;topic=3720.0;attach=7284) in EGA)

(http://forum.stunts.hu/index.php?action=dlattach;topic=3626.0;attach=7576;image)  (http://forum.stunts.hu/index.php?action=dlattach;topic=3626.0;attach=7578;image)


Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 10, 2021, 03:49:01 PM
I have noticed something similar too, and like you, I cannot be exactly sure about why, but some actions seem to reduce or eliminate the chance of these bugs happening. Reading the values from original cars, I've seen that both the X displacement and the width W for every image are always multiples of 8. The Y and the height H don't follow this rule, but of course, with the first rule, if you multiply these, you'll always get a multiple of 8 as well. However, playing with these values and changing them seems to have no effect... until it does!  In other words, Stunts does accept other values, but if you stick to those, you know some bugs won't occur.

About INS1 and INS3 and their corresponding masks, I agree that the best is to use the same dimensions as those of INS2 and set X and Y to zero. That's the safest. Yet, looking at original cars, which usually do not follow this rule, I find that these two images are always aligned at the bottom-right and bottom-left of INS2 and their X and Y seem to be ignored, yet values are saved there!  I also saw that the unknown word fields are a vector too!  And when two Xs have a certain delta, the first of those words (unknown X) appears to also display the same delta. Again, nevertheless, changing this vector appears to have no effect!
Title: Re: CarWorks - a different approach to car making
Post by: KyLiE on May 10, 2021, 05:38:12 PM
It turns out that when I edit these image resources to make a perfect rendering in the context of CGA or EGA game setup, there is some misalignment rendering "ins*" and "whl*" that I think it has relation with the width x height pixel proportions.

I've noticed this as well.  Speaking of which, I've asked about this in another topic (http://forum.stunts.hu/index.php?topic=3744.0), but do you have any information on the translation tables for the alternative CGA and EGA palettes?  I know how they work, but I would like to make a list of each alternate colour/shade and its corresponding value and I'm not sure which is the best way to do that.
Title: Re: CarWorks - a different approach to car making
Post by: Zapper on May 10, 2021, 06:06:17 PM
It turns out that when I edit these image resources to make a perfect rendering in the context of CGA or EGA game setup, there is some misalignment rendering "ins*" and "whl*" that I think it has relation with the width x height pixel proportions.

I've noticed this as well.  Speaking of which, I've asked about this in another topic (http://forum.stunts.hu/index.php?topic=3744.0), but do you have any information on the translation tables for the alternative CGA and EGA palettes?  I know how they work, but I would like to make a list of each alternate colour/shade and its corresponding value and I'm not sure which is the best way to do that.

I think there is no direct translation between pallets, if you compare the dashboards show above (http://forum.stunts.hu/index.php?topic=3626.msg79996#msg79996), a simple plain "yellow" on the MCGA / VGA pallet is rendered as a "striped" pattern in CGA, but not in EGA... And other examples like the windscreen or the steering wheel, just by visual comparison we find color patterns apearing in different places of the same dashboard.
So, I believe that several other mechanics are implemented in the game engine.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 11, 2021, 12:06:18 AM
I don't think I'll be covering the EGA/CGA palettes in CarWorks, at least for now. Too complex and there are other, more common things, we still don't fully understand. Maybe in the future, when we have a clearer understanding of it and the rest has been sorted out.

I'm really puzzled to see that, when the width of ins1 and ins3 differs from that of ins2, that first pair still shares the same width and coordinates, yet, they are not placed at the same location, one being aligned to the right and the other one to the left. I wonder if the one on the left gets its position calculated from right to left or if it just ignores the X. I'm going to have to run some tests.
Title: Re: CarWorks - a different approach to car making
Post by: KyLiE on May 11, 2021, 04:48:07 AM
I don't think I'll be covering the EGA/CGA palettes in CarWorks, at least for now.

I didn't think you would be.  The only reason I mentioned it is because I haven't had much response to the other topic (http://forum.stunts.hu/index.php?topic=3744.0) and when I saw Zapper mention it, I thought I'd ask.
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on May 11, 2021, 11:39:17 AM
I'm really puzzled to see that, when the width of ins1 and ins3 differs from that of ins2, that first pair still shares the same width and coordinates, yet, they are not placed at the same location, one being aligned to the right and the other one to the left. I wonder if the one on the left gets its position calculated from right to left or if it just ignores the X. I'm going to have to run some tests.
I can not reproduce this statement. In the February 25, 1991 edition all looks normal. all offsets are correctly given for ins1.
Can you give me an example where (or when) this is not so?
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 12, 2021, 02:23:11 AM
Sorry... I've been making more tests and it looks like I was somehow reading the data incorrectly. X and Y coordinates match the correct position for ins1 and ins3, relative to the coordinates of ins2.

It would indeed be nice to eventually support the CGA/EGA graphics one the palette format were fully understood. I'm not prioritising it now, but hopefully, when CarWorks already does everything it has to do, we can have an implementation for this in the program
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on May 12, 2021, 01:57:55 PM
- The image resource "ins2" should have a certain WxH that results in a integer value when divised by 8, for example:
    on Jaguar JR9 "ins2" has 48 pixels width and 34 pixels height:
         48x34=1632 -> 1632/8=204
    the result 204 has no decimal value, so it should be ok.
    I also use this rule on "whl1-3".
Since i don't have any programming experience or detailed understanding of the inner workings of the code I try to understand this matter theoretically and by comparing it to other things I come across.

In reading the forum and the wiki I found some bits interesting.
- all dashboard (part) images have a with of a multiple of 8 in the original cars.
- the game was made with time pressure
- its build with a lot of concessions in favor of memory usage.
- and some other things that nagged my brain.

If you divide the 320 pixels in part of 8 you get 40 columns.
That made me think of old 2d graphics (like in Commodore 64 and such)

Could the dashboard animation be like that and therefore work with images and parts in multiples of 8?

It's an idea, and it does not hold if the quoted statement is true for cases where X is not a multiple of 8.
It does however seem to fit all original cars.

Maybe it's noting... Like I said. It's not based on anything solid. Just a link I made between bits of information that may or may not have any relation.
I don't even know if the bits of 8 are a restriction in commodore and such.

Afterthought:
Maybe the engine just maps area's of 8 as animated parts and the others as static. Then only the columns with animations have a render cycle and the other parts do not.
that would save memory as well...
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 13, 2021, 03:28:03 AM
Well, this is all speculation from my part, but, in my opinion, the multiple-of-eight rule is part of a strategy of optimisation for speed. We know the following:

On a side note, I've just uploaded another snapshot of CarWorks to the project page. It already contains some Dash Manager code, but not to the point of it being useful. You can load VSH files and see the images, even "drive", moving the steering wheel, but that's it for now. I don't remember how I had left the 3D part before this update, so maybe you find a difference there as well.
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on May 13, 2021, 09:57:02 AM
That makes more sence  8)
Title: Re: CarWorks - a different approach to car making
Post by: Zapper on May 13, 2021, 05:45:47 PM
Cas, for me those considerations are safe enough to take into account on developping this tool.  ;)
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 19, 2021, 04:26:35 AM
Alright. I'm proud to announce that the first snapshot of CarWorks 1.0 that can do everything that the old CarWorks 0.1 and Dash Manager 0.1 could do is already up. Of course, it not only can do that much; it can do a lot more; but I felt it was a requirement to get to this point so that the old alpha versions can now be considered obsolete. As a result, this snapshot is now an official release and version 1.0 will apply to it alone. Next time I upload changes, I'll be modifying the version number.

Anyway. The package is, as usual, in the project site, which will soon be upgraded, at http://www.raceforkicks.com/projects/carworks.html (http://www.raceforkicks.com/projects/carworks.html). You will notice that the file loading and saving part of the program still looks ugly, but it does its job. I've been leaving that for the end to be able to complete the tools as soon as possible. The three parts are implemented, to a reasonable degree: the 3D modelling and paint-job section, the parameter configuration area and the dash manager, that now has become part of it and hopefully, is more stable and doesn't have as many bugs.

I would like you guys to put the program to the test of normal usage. I have been testing each feature I implemented, but I am not actually building a car, so it's likely that some bugs will have come unnoticed by me. Thank you all so much for your help so far and of course, I'm open to suggestions. I'll be focusing in improving the file handling section now and fixing any bugs that come up. Cheers!
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on May 19, 2021, 07:00:13 AM
Congratulations and thank you. I have no project for the moment but I will surely try it.
Title: Re: CarWorks - a different approach to car making
Post by: KyLiE on May 19, 2021, 04:54:56 PM
It's great to hear that you have reached that milestone!  As you know, I have been delayed with the development of the Chevrolet Corvette CERV III.  However, when I get the chance I will definitely be using the latest version of CarWorks to continue working on it. :)
Title: Re: CarWorks - a different approach to car making
Post by: afullo on May 20, 2021, 09:05:55 PM
Thanks, Cas! Btw, there is still the same problem with the libraries affecting Bliss, so I compiled a version for Ubuntu 18.04 and derivatives. Unfortunately, I am not able anymore to compile for 32-bit systems, since the hard disk containing that installation broke down in April, and I reinstalled the system in the new one as 64-bit.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 22, 2021, 12:22:45 AM
Thanks, guys!  I'll try to have an update with a nice file management system soon. There are many things I want to add and fix.

Afullo, thanks for the .so5-based binary. I'll make sure to include it in the package. CarWorks is now at official level, but still in an early version, so I expect it will have many updates and I don't know if you'll always be comfortable with producing another such binary. When you're to busy to do it, I'll understand. I think I should just make a virtual machine for these things, but even that would take lots of time and sometimes I just want to compile the program quickly and use the time for programming.

My job has also been absorbing much more of my time than it happened with the previous one. As a matter of fact, I've been working the two jobs and will continue to do so till the end of the month, when I'll be dropping the old one.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 27, 2021, 02:56:14 AM
Update

CarWorks 1.0.1 is out!  New features include:
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on May 27, 2021, 10:31:57 AM
CarWorks 1.0.1 is out!  New features include:
  • Also via the configuration file, stunpack can be integrated, to provide support for compressed car files
Can you make it automatically detect and unpack? And make repack a checkbox?
I'm a dyslectic and have a slight allergy to configurations files.   8) 8)

Very nice work overall though..
Title: Re: CarWorks - a different approach to car making
Post by: afullo on May 27, 2021, 03:28:35 PM
I attach the .so5-based binary.

Afullo, thanks for the .so5-based binary. I'll make sure to include it in the package. CarWorks is now at official level, but still in an early version, so I expect it will have many updates and I don't know if you'll always be comfortable with producing another such binary. When you're to busy to do it, I'll understand. I think I should just make a virtual machine for these things, but even that would take lots of time and sometimes I just want to compile the program quickly and use the time for programming.

It takes me only the download and the execution of a single command, but it could happen sometimes in the future that I will be unable to produce it, at least just shortly after the release. In the case, I'll post it as soon as possible.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 28, 2021, 12:22:05 AM
Quote from: Daniel3D
Can you make it automatically detect and unpack?
It does automatically unpack a file if it sees it's packed (extension is P3S, PVS or PRE), but I think you mean like it should auto-detect if you have stunpack installed. Is that right?   I could make it to first check to see if you have specified a path to stunpack in the configuration file and, if you haven't, test to see if the program is in the same directory as CarWorks and then use that one. That way, you just have to copy it there. The simplest thing you can do currently is make sure stunpack is at some location in your PATH and then edit the configuration file to make sure it contains a line that says "stunpack=stunpack".

I could include stunpack in the package, but that would bloat the Zip file unnecessarily. Besides, while I'm sure Dstien's intention was to make stunpack free software, he doesn't seem to have specified the license for it.

Quote from: afullo
I'll post it as soon as possible.
Thanks!  I've downloaded the binary and I'll include it in the package. Don't worry if you ever don't have the time to do it. Besides, time is passing and soon most distros being used will have version 6 installed. What I really would like to find is a way to statically link these libraries so this wouldn't be a problem any more or find a way so that the program no longer needs it because the library actually is dedicated to console-based environments and this is a GUI based project.
Title: Re: CarWorks - a different approach to car making
Post by: afullo on May 28, 2021, 12:32:52 AM
Thanks!  I've downloaded the binary and I'll include it in the package. Don't worry if you ever don't have the time to do it. Besides, time is passing and soon most distros being used will have version 6 installed. What I really would like to find is a way to statically link these libraries so this wouldn't be a problem any more or find a way so that the program no longer needs it because the library actually is dedicated to console-based environments and this is a GUI based project.

Ubuntu 18.04 and its derivatives are supported until 26 April 2023, so it would be of some use for still a couple of years. I do not plan the upgrade to 20.04 before the summer of 2022, as I upgraded from 14.04 to 16.04 in June 2018, and from 16.04 to 18.04 in July 2020.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on May 29, 2021, 01:12:27 AM
I already included the file in the package. Of course!  The LTS!  Well, if you do upgrade or just get tired of posting the binary, ha, ha, I could make a VM with an old Ubuntu LTS.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on June 11, 2021, 03:16:36 AM
I updated CarWorks to version 1.0.2. It's still lacking several things, but I've made some important improvements.

Namely, I've fixed the issue that caused some files to appear as directories in Windows and I made a lot more things controllable with the mouse in the Dash Manager section. Also, you get some simple, but useful notices in the file menu when you load or save a file and you can load or save a whole car project by entering the four ID letters only, without extension. This is a little crude and is not working wonderfully, but is there and saves time. Finally, I have also given CarWorks an icon and I updated the project website under Race For Kicks and the wiki article.

There can be some bugs in this version, but I think all in all, it's mostly improvements. Wine does not make a great work showing me how it behaves, so let me know if you find some bugs. Due to drives now being supported in Windows, I expect bugs in the file list menu. Also, Wine shows the icon in gray colour instead of green. Does it look that way in true Windows too?
Title: Re: CarWorks - a different approach to car making
Post by: afullo on June 11, 2021, 10:13:58 AM
I attach the .so5-based binary.

Due to drives now being supported in Windows, I expect bugs in the file list menu.

Sometimes, the dots for returning to the previous directory are not shown, I don't know if spaces in the path are the cause.

Also, Wine shows the icon in gray colour instead of green. Does it look that way in true Windows too?

True Windows shows the icon correctly as green.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on June 11, 2021, 08:21:33 PM
Thanks for the compilation again, Afullo!

Uhm, I really don't know about the dots. I very rarely use spaces in my directories, so I didn't realise. I'll put that to the test. Honestly, I don't think that's the reason because the program does not parse the directory path, but instead just uses a command to read the whole of it, but who knows. I'll have to test that. Another thing I can do is simply force the program to always generate the ".." directory unless you're at the root.
Title: Re: CarWorks - a different approach to car making
Post by: afullo on June 13, 2021, 05:25:20 PM
Thanks for the compilation again, Afullo!

Uhm, I really don't know about the dots. I very rarely use spaces in my directories, so I didn't realise. I'll put that to the test. Honestly, I don't think that's the reason because the program does not parse the directory path, but instead just uses a command to read the whole of it, but who knows. I'll have to test that. Another thing I can do is simply force the program to always generate the ".." directory unless you're at the root.

You're welcome! I tried to create another folder with spaces in the path ("spaced folder" at the same level of "carworks102" attached in a previous picture): the dots are correctly shown, so this is not the cause in general.

Maybe it has something to do with the standard Windows folder "Documents and Settings"; anyway,  it is not generally a good practice to use spaces in folders' names, but since all the modern operative systems allow it, some of us do not take care of avoiding it at all anymore.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on June 13, 2021, 08:13:27 PM
Can you tell me whether Bliss displays the same behaviour with the same directories?
Title: Re: CarWorks - a different approach to car making
Post by: afullo on June 14, 2021, 01:33:38 AM
Bliss does not see "Documents and Settings" and various other folders of C:, see attached screenshot. On the other side, in "spaced folder" the behaviour is the same, with the dots correctly showing.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on June 14, 2021, 08:48:43 PM
Ah, yes... CarWorks does not filter out system or hidden files. I realised that FreeBasic, in its attempt to make its file functions compatible across the OSs, does not always correctly recognise file attributes. If I want to make it work well for Windows, it'll cause problems in Linux and vice-versa. The only good solution is to just request the whole contents and do the filtering myself and I chose to just not filter anything. I figure that directory must have a system attribute, probably.

But do the ".." appear always to you in Bliss?
Title: Re: CarWorks - a different approach to car making
Post by: afullo on June 14, 2021, 08:53:13 PM
For the moment, I haven't found cases in which they do not appear, in case I would discover one I will alert you...
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on July 24, 2021, 06:49:03 AM
Finally, I tried the new version. First of all, I want to recall how I made a car :
- modelize under stressed with the help of my Excel speadsheet and paint.
- carwork to edit res value and the speadsheet
- hex editor for torque curve with the speadsheet
- GIMP for dashboard with dashman.

With your new carwork, I lost 2 features :
- when I load with old carwork the 3sh and savez it, it created car1 and car2. Is it always the case ?
- in dashboard mode, I select the bmp file for the dashboard but it doesn't load it. Maybe I made a mistake.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on July 25, 2021, 04:59:33 AM
Quote from: Ryoma
when I load with old carwork the 3sh and savez it, it created car1 and car2. Is it always the case ?
Do you mean like load a 3SH into CarWorks and then save a model as OBJ?  If so, looking at old CarWorks code, it appears that only the car0 shape could be exported to OBJ. With CarWorks 1.0, you can export any of the shapes. You first need to select the shape you want to export and then save it as OBJ.

Loading an OBJ has also changed to be more flexible. In CarWorks 0.1, you would load the OBJ file to a vectorised shaped and if you later saved it as 3SH, the same shape was scaled and written to each of the three car0, car1 and car2. With CarWorks 1.0, you load an OBJ file into the current car shape and the other two remain unchanged. If you want, you can then use Ctrl+C and Ctrl+V to copy this shape onto the other two shapes. When saving, the shapes will be scaled accordingly. The thing is now you have the option of using different OBJ files for the different shapes if you want. Let me know if you have any difficulties with this feature.

Quote from: Ryoma
in dashboard mode, I select the bmp file for the dashboard but it doesn't load it. Maybe I made a mistake.
Yes, this is a problem. Old CarWorks also had it, more or less. It happens because FreeBasic (the language I've used to make CarWorks) includes its own BMP loading routine, which is not perfect. It will only accept 32 bit uncompressed BMPs (not 24 bit, that is, they have to have an alpha channel). I developed my own TGA (Targa) library, so if you load from Targa, you won't have this problem. Also, you lose transparency when you load BMPs. I could solve this by making my own BMP functions. In the meantime, I recommend TGA.

Another FreeBasic programmer has made a library that supports several graphics formats based on a public domain library in C. I think I could incorporate it into CarWorks to provide better graphic format support.
Title: Re: CarWorks - a different approach to car making
Post by: alanrotoi on August 14, 2021, 05:58:29 AM
I think I found a problem with carworks. When you "play" with the physical parameters you may have unwanted effects. In common cars when you jump and land the car on road ALWAYS you increase the speed if you are accelerating. Always. I'm building Dodge Monaco Highway Patrol car with carworks and sometimes it happens.
It happens with BMW DTM and maybe (can't remember well) with Mercedes DTM too. It's not proper for this stunts version an effect like this. Was BMW built with carworks?

It never happened with car blaster. I say it because maybe the way you face the parameters from the code of carworks could add this unwanted effect.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 18, 2021, 02:25:43 AM
Uhm... I don't see how this could be possible. I mean, CarWorks only reads the parameters and shows them as they are. You edit the values and it puts them back in their corresponding places in the file. In other words, it does the same thing as Car Blaster. Only difference is that it can read any ordering of the chunks and the ordering it uses when saving is not the same as the one Car Blaster uses. Reordering the chunks should have no effect on the physical parameters, but if you want to test that, I think you can reorder them with Stressed.

When the DTM pack was released, CarWorks either didn't exist or was in a very early phase (of the 0.1 version). Either way, I'm sure that Overdrijf did not use CarWorks back then.

If you find that reordering has an effect, I'm interested in knowing it!
Title: Re: CarWorks - a different approach to car making
Post by: alanrotoi on August 18, 2021, 05:33:24 AM
Oh I guessed those cars were new. So it's a problem of a bad testing cars. The effect is just what I said. Sometimes when the car lands after a jump it doesn't accelerates. It keeps the previous speed just like happens in BB 1.0. But it's only sometimes. You have to redo  the jump until it "catches" the extra speed. Seems to be a bad combinations of parameters from the user and not the programs.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 23, 2021, 01:04:06 AM
Stunts physics engine is pretty mysterious. I would think that this effect might have something to do with the rounding of fixed-point numbers after division, kind of like what happens between power gear and car mass. In fact, I wouldn't be surprised if this effect also had to do with the car mass number!
Title: Re: CarWorks - a different approach to car making
Post by: alanrotoi on August 23, 2021, 03:44:18 AM
Also it might be related with some of the changes made between BB1.0 and BB1.1. This "unwanted effect" was normal in BB1.0 version and then disappeared in BB1.1.

Oh well now I think maybe not :D.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 24, 2021, 04:00:57 AM
Well, I have to say that, while I love Stunts more than any game, I've been concentrating more on designing tracks than on becoming a good pipsqueak and being a good pipsqueak includes things like putting attention to the physics of the game, noticing subtle details and learning to exploit them well. You are certainly a lot more skilled than I am at this!  Many of the physics-related tricks and bugs in Stunts that are very well known and often documented in this forum and the wiki I had never heard of or noticed before I first read them here. I dare say, the only one I was aware of before coming across the Stunts online community was power gear.
Title: Re: CarWorks - a different approach to car making
Post by: alanrotoi on August 24, 2021, 05:19:05 AM
the only one I was aware of before coming across the Stunts online community was power gear.

Hey me too! I learned more in the first year here than before or after that year. The only bug I knew was power gear but only in INDY. So when I raced my 3rd race (the well known zct16 replay) the car was Acura and everybody started to talk about using power gear and my face was like O_O.

By the way this normal effect (accelerating when landing) it's not a bug.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 27, 2021, 11:52:41 PM
CarWorks 1.0.3 released!

Some useful updates:
As always, you can get it here: http://www.raceforkicks.com/projects/carworks.html (http://www.raceforkicks.com/projects/carworks.html)

Quote from: Alan Rotoi
By the way this normal effect (accelerating when landing) it's not a bug.
You're right!  Rather, it's the lack thereof for some cars that is a bug. I wonder why that would happen...
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on August 28, 2021, 03:59:12 AM
Questions :
- is there automatic color ? For example, I draw in ref with palette from 52 to 55, and after the software create new paint (76 to 79 for example)
- automatic color for exp depending of color from car0...it's very boring to think about this..
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on August 28, 2021, 08:47:28 AM
Questions :
- is there automatic color ? For example, I draw in ref with palette from 52 to 55, and after the software create new paint (76 to 79 for example)
- automatic color for exp depending of color from car0...it's very boring to think about this..
Why not make debris standard gray and black. Until there is a more elegant solution.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 28, 2021, 01:17:57 PM
Yes, there is automatic colour and CarWorks can already generate debris based on current car colour. There is only one little limitation that I'm also going to solve. So, to use automatic colour, you do this:

- First, you make your model in Blender or another external editor and you give it colours there using the palette colour names as usual or... you may leave it colourless at this point
- Then, you export this to OBJ and import it with CarWorks. If you have used colours from the palette, they will be imported. Otherwise, you can auto-shade the car with Ctrl+A and then apply one of the paint jobs to it. Of course, if you do it this second way, all car primitives will be painted, so you may want to go back to Blender and paint windows, bumpers, etc., with another colour, then export and re-import
- From this point onward, you can add new shapes by copying from this one (Ctrl+P) and colour them one by one with the paint job list (Enter, while hovering over the 3D shape). If you use the classical paint jobs, this will work perfectly well. If you use custom paint-jobs, it's one-way (for now)
- You can generate debris (Ctrl+D) at any time and it will automatically select random primitives from the model for each of the paint jobs. The colours will agree with the current car colour. If you update the paint jobs, you should re-generate the debris, so that it agrees with the new paint jobs.
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on August 28, 2021, 10:39:09 PM
Or, use shading in carworks, save
Load in stressed. Color windows and lights and other details, save
Load back in carworks and...
Quote
From this point onward, you can add new shapes by copying from this one (Ctrl+P) and colour them one by one with the paint job list (Enter, while hovering over the 3D shape). If you use the classical paint jobs, this will work perfectly well. If you use custom paint-jobs, it's one-way (for now)
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 29, 2021, 12:40:13 AM
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.
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on August 29, 2021, 09:44:21 PM
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.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 30, 2021, 04:04:52 AM
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:

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.
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on August 30, 2021, 08:11:00 AM
Cas could you try on my XM ?
Title: Re: CarWorks - a different approach to car making
Post by: Daniel3D on August 30, 2021, 10:51:22 AM
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.
Title: Re: CarWorks - a different approach to car making
Post by: Ryoma on August 30, 2021, 02:42:37 PM
again this limit to 5. Look my shape.
Title: Re: CarWorks - a different approach to car making
Post by: afullo on August 30, 2021, 08:35:53 PM
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]
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]
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?
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 30, 2021, 11:36:03 PM
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.
Title: Re: CarWorks - a different approach to car making
Post by: afullo on August 30, 2021, 11:56:55 PM
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.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on August 31, 2021, 01:21:54 AM
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]
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.
Title: Re: CarWorks - a different approach to car making
Post by: afullo on August 31, 2021, 07:04:13 PM
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.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on September 23, 2021, 11:25:45 PM
New update! - CarWorks 1.0.4 is out :)

New features include:

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.
Title: Re: CarWorks - a different approach to car making
Post by: afullo on September 26, 2021, 01:23:44 AM
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.
Title: Re: CarWorks - a different approach to car making
Post by: KyLiE on September 26, 2021, 07:52:18 AM
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.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on September 27, 2021, 03:12:39 AM
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.
Title: Re: CarWorks - a different approach to car making
Post by: KyLiE on September 27, 2021, 06:25:04 AM
I've just tested CarWorks on both x86 and x64 versions of Windows.  Clicking on drive letters behaves the same way as I mentioned before.

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?

I expected it to work like Bliss because I think it's better that way.  I simply mentioned Bliss to make sure that you knew what I was talking about.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on September 27, 2021, 11:19:47 PM
Good, then!  I'll take a look and see if I can get that updated!
Title: Re: CarWorks - a different approach to car making
Post by: afullo on September 30, 2021, 05:19:56 PM
Quote from: KyLiE
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.

Quote from: 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?

In fact, the behaviours are consistent, since I tried on a PC with only one drive, so the last selected directory on that drive is of course the current directory, thus resulting in nothing happening. I will try connecting an external drive in order to have at least two disk units...

EDIT: ok, by having two drives, it behaves exactly as for KyLiE does.
Title: Re: CarWorks - a different approach to car making
Post by: Cas on October 03, 2021, 03:42:57 AM
Ah!  Thank you so much. Now I understand exactly what is going on. So then, you also think it'd be more comfortable like Bliss does it?
Title: Re: CarWorks - a different approach to car making
Post by: afullo on October 03, 2021, 11:25:27 AM
Maybe it would be perceived as more logical, although personally it wouldn't make a particular difference.