Messages

The overflow at 32768 tics can be confirmed by taking a penalty time such that the sum with the elapsed time is higher than 27:18.35 (32767 tics): the total time would be displayed as negative, as in an earlier topic from 2018 I already showed (I'm from phone and unable to link it on the fly, but in the case I will be able later).

2021 update. This year the seasonal scoreboard and the racewise constructed one do agree.

I would like to continue with my current team if the guys agree

Agree

OK, we can confirm Rolling Stunts!

Because of the way wheels are defined in the 3SH file, it should be possible. However, rendering may look weird, as Stunts will consider either the top or the bottom side of the wheel to be "inner" and the other "outer". You surely noticed that when cars are rotated in any other axis than the vertical, wheels tend to appear strange. I think this is because Stunts tries to render ellipses orthogonally with respect to the screen or to some coordinate system. This might affect the wheel look. We'd have to try it to see.

It remembers me of using a Doom port which allows freelook, but does not improve graphics. While seeing some entities by watching not horizontally, they could look as they underwent a shear transform.

CTG's 2014 disqualification. Since it didn't have to do with his results as CTG, in principle his race results should stand, with only the assignment of points being changed. This WIki article documents the affected races.

It was fun to be proclaimed winner of the newbie league in March of the next year, when the "Agro Brothers" Rokker Zsolti and Boller Jani were exposed to be CTG's ghosts, as at least one dr1v3r conjectured still during the season... 

@afullo my definition of an amateur : someone who never made a podium.

That could make sense. But posting a replay as an amateur implies to make it public, which can be not convenient in light of the main competition.

As Julian Bashir said in Star Trek DS9: 3x17 Visionary, who am I to disagree with myself? 

[Cars]

Some thoughts before heading to sleep:

Cars are going to be tricky! Thanks to Ryoma, but not only, there is suddenly a bunch of new cars. Most of them are "untested" in a racing situation though, and we don't know if they have any peculiar and interesting traits. We'll need a short-list if we want to consider any for the next season. Note that I don't plan to increase the number of total cars, or the proportion of custom cars. Revised Melange in for sure!

I agree with asking, first of all, Ryoma which cars are better suitable for this competition.

Amateur league: we'll continue this experiment until the end of the 2021, but in early December we'll have to decide if we want to make it "official" and code it into the website. See specific thread.

As Alan said, we have to define rigorously what an "amateur" is. I have been played since February 2014, seriously the first year, less seriously during 2015-2017, and again seriously from 2018 onwards. Nonetheless, Ryoma is able to place himself ahead of me, probably with statistical significance, when he plays at his best. In light of this, since he defines himself an amateur, have I to be considered an amateur too, or not?

Track ratings: track scores for 2021 will become visible at the end of the season, giving us the Track of Year; I don't know if there'll be time to revise the system, so it's likely to continue as it is for 2022. We can improve it for 2023 if needed.

Unfortunately I generally forgot to rate tracks, so I will be probably able to say something not before the next year.

GAR: my idea at the moment is to phase out GAR for 2022, and replace it with a more relaxed OWOOT tag, which allows replay handling. GAR could be back in 2023, or not, we'll see next year.

I agree. A competition with the R4K rules could attain larger participation, since it brings some frustration to repeat a whole lap just because of an error while driving the last tiles, although GAR is a good selector for strong dr1vers.

Teams: we discussed some changes earlier this year, but didn't get very far; feels like to much stuff on the plate now that we are planning the Amateur league, but I'd like to keep that discussion going.

Of course, to create equilibrium between teams, it could be a good way to bring more interest to the team competition, both for dr1vers which are already part of a squad, and for those who aren't.

Maybe it would be perceived as more logical, although personally it wouldn't make a particular difference.

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.

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.

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.

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.

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.

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?

Terrific! I have one in my garage too...