Messages

Sausage

as soon as you would try to write a multi-platform wrapper (capable as SDL2-3) around input,output,sound,etc. you would see that the SDL api is really small for what its helping/keeping from you - you're just not used to it - thats all

It may seem so because we now see everyday programs taking up hundreds or megabytes or gigabytes, but really, it's huge. Take the most complicated game from the 90s, strip out data (animations, graphics, audio) and you'll see the code is rarely more than a megabyte. SDL is a layer on top of a layer, on top of a layer and so on. The degree of dependency and lack of knowledge of how the code works is extremely high. No person that worked on it understands all the code and nobody making programs for it does either. Besides, if you only need to load a PNG file and then save it, you depend on code that can also process compressed audio, for example. It's like carrying the computer with your program.

Yes it does. All you have to do is make your graphical and sound functions work with all 3 versions of SDL, which is what I did.

Which brings me to this. If you send somebody a letter in a random language and you accompany it with a guy who speaks a hundred languages including it, you could say the letter is written in a lingua franca, but that's not true. It's the translator that makes it seem so. And of course, you can send the letter in an envelope, while carrying the guy overseas may require a seat on a plane or a room in a ship. But SDL not only does this, it also doesn't even provide the translator guy: it just tells you that translator exists and you have to find it and bring it home yourself, ha, ha.

---
I realise all this may not matter to many people. Some of us may be very picky with their food, but can sleep anywhere, while others can eat rubbish, but then need a comfy mattress. I like clean, logical, comprehensive code... I don't like using black boxes. I feel the need to have full control and know what I'm doing. Not having that is uncomfortable to me and even very boring, because seeing the inside mechanisms of things is what has attracted me to many things I'm passionate about, including programming.

Oh, it's really sad to read this   I don't see how this could have been accidental. I have planned a system to detect this automatically in R4K since a long time ago, but it never seemed necessary. I guess I'll have to find the time to do it and in the meantime, put attention to coming replays.

Hey!  As you guys know, I'm travelling. Soon will be back. Just wanted to clarify about my opinions on SDL. I do think SDL is a very good tool and I don't mean to say at all that programming for SDL is in any way easier than programming on a library that's built into the compiler. I just find that SDL is in itself like a language and programming for it in C is a very different experience from just making a C program (or C++). On the other hand, what I try to achieve with my programs is some portability (through time, more than from platform to platform, but both are good). I have not been very successful on that in GNU/Linux and I keep trying to improve that. SDL does not solve this. It solves other things. Still, I've been interesting in trying it many times, but well, I'd like to solve my portability problem first of all. So far, the only solution appears to be to program for DOS

I don't really have a problem with SDL. I think it's good. It just doesn't do what I want to do. It's good for SDL to exist because it makes a standard instead of letting tons of different libraries take over. That's a very good thing. But programming for SDL feels very different to me from programming in a language. The library takes over and you really are no longer writing the graphics code. I was a low level programmer in DOS. Now, for GNU/Linux, that's practically banned, so I try to do the closest to it that is possible and SDL is not it. SDL is not C... it's SDL. With SDL, I'd feel that I'm no longer writing programs for the OS, but I'm writing scripts for some program. "SavePNG" (or whatever it's called) -> Boom!  You have a PNG file. I don't like that. Then wanting to copy and run a 2MB program and having to download half a gigabyte from the internet for it to run.... Also not my type.

X11 (or Wayland) is part of the OS. It comes installed with it unless you're using a server distro. SDL is not. FreeBasic is semantically abstract from graphics libraries: it can describe graphics code. C cannot. When you program graphics in C, you're not really programming in C. I like comprehensive graphics code.

FreeBasic, the language, has nothing to do with hardware (or software) support. If you write a program in FreeBasic, maybe the compiler will build it for Wayland or maybe not and in the future yes. I don't know. I don't have to worry about it because I can read the code and understand what it does. If needed, I can actually plug FreeBasic to SDL, although I think it does it wrap it under the syntax, which would be great. That's why I prefer the default graphics functions.

@dstien - That's amazing. Yeah, I'd like to be able to write a function that performs exactly the same and the physics engine and compare the car positions. Your porting will be a lot more optimal, of course. I just want to be able to see that I understand it and have it in my mind analytically, not just copying the code.

But mostly yes, my interest is on putting that in the core and build shells out from scratch. I wonder how much is in the core that limits what can be added outside. For example, if there are references to the current memory distribution of track elements, maybe it isn't possible to make a bigger map without modifying the core. But perhaps the required changes would be minimal. I don't know.

@Matei - I think here is a misunderstanding. I'm going to get a little philosophical here, but just to clarify... Yes, my engine is a proof of concept. I wrote it to build and see that it actually did the thing and I didn't make any effort to make it fast enough or to perfectly render things without glitches, so it's not ready be to put on a game.

Now, this unfinished nature of it has nothing to do with it being FreeBasic. Because it is a graphical engine, it is impossible to port it to C, as C has no graphics functions. What you surely mean is to port it to SDL. I don't have much interest in doing that as there are tons of SDL-based 3D graphics engines out there already. They're not bad, but why reinvent the wheel?  I would like to create a new painter's algorithm based engine analog to Stunts' original and software based, like that of Stunts, that runs natively on modern systems and allows for adding some more things. That's it.

There's a difference between translating code between two programming languages and porting code between two compilers. Porting is about creating a source code that can be compiled with another tool chain and result in a different binary that can be run on a different platform. Translating has to do with the syntax, with the language. Libraries play no role in translation and there's no software efficiency optimisation in translating code. In terms of languages, considering the functions that are present in FreeBasic and C and their definitions, there is no superiority in one on the other. Maybe we could say FB is superior because it can do graphics comprehensively, while see cannot (as a language). In terms of the compiler, there are many C compilers, most of which have had much more work on than FreeBasic's and are likely to be more efficient, but when talking about graphics code, since C does not include that, the C compiler will just "copy and paste" from the 3rd party library, say, SDL, so if you make a game in FreeBasic or in C that uses SDL, efficiency will be the same as regards graphics.

Beyond superiority, there's a trend of preference towards the C language (syntactically) because it's more commonly used and you have more compiler options. This makes a lot of sense and I would recommend to follow suit for non-graphical projects.

Wow!  Another important historical detail for 4:00am! 

Amazing, @dstien! 
Is it possible to isolate the physical engine for analysis?  I feel that many parts of the code, such as the menus, file loading functions, etc., would be easier to rewrite than to port, and the graphics engine, while more significant, is the one that could use an upgrade, but the physics engine is crucial so that we can actually reproduce the behaviour, remain replay-compatible, etc. If we could work shell by shell around the physics engine, great things could be achieved!

I happens when you use C too. You can only avoid it if you have absolutely everything statically liked. Unfortunately, nowadays, libraries are bloated and designed in a way that makes that completely impractical. In GNU, there's an additional problem because the system is designed to make it very hard to link things statically. In the end, we're forced to use virtual layers, such as Wine, JVM, SDL or DOSBox because programs break from a computer to another or from an OS version to the next and as a result, nobody truly knows how to program a real computer anymore.

Don't worry, mate. Most of us that participate in both tournaments sometimes don't realise and just skip something out of habit. I always check my own replays top down after recording them and often find something that means I'll have to redo them

Older versions of Bliss were 32 bit, then I began posting both, but eventually, it became very complicated to compile it for both architectures, so now I only compile (GNU/Linux) for 64 bit. I'm planning to create an AppImage to simplify the thing. As regards Windows, I don't use this platform myself, so for compilation, I use Wine and FreeBasic for Win. I don't remember if that one is available 32 bit on the site.

Hey, team mate!  Glad to share this season with you in spite of the instabilities of this year. Your racing is as always superb and we have a good environment in our team chat. I totally understand your wanting to take a rest from this, though.

Things we've gone through this year would've been even more stressing to me if it weren't that my job is taking so much time and effort that when I get to do something in Stunts, I am only half-focused and I kind of don't feel all the bullets. I appreciate all the people who have shown their interest in putting their effort to make things more positive. Like everyone, I keep learning how to be a better member of a community. Hope the best for seasons to come and that the environment keeps improving so you feel with the energy to return.

Airplane (from Lockheed Martin and Learjet)

Hey, stanceboyCZ!  Yes, we really appreciate your participating. The rules are on the site, but if you have any doubt or just prefer to ask us, we'll be glad to help you. Also, in December, we'll have a special event. We often use Free OWOOT or Free-Style rules for the last race. Sometimes we do for some other race in the middle of the year, so don't miss that one.