Stunts Forum

Stunts - the Game => Stunts Related Programs => Topic started by: Cas on September 22, 2018, 11:27:32 PM

Title: Modern system native Stunts proto-engine
Post by: Cas on September 22, 2018, 11:27:32 PM
Guys, I made this very, very simple proto-engine last year and left the project because of a difficulty I know I cold overcome with some hard work. Now I was thinking it's there so I can share it with you and maybe eventually give it another push. What I'm posting is the GNU/Linux 64bit compiled version. I didn't compile it for Windows because I would first have to install a 32bit Linux and then Wine on top and the compiler (I don't know why, but Wine doesn't seem to work with 64bit Linux for me), but I can later get that done and post it too.

Use the arrow keys to look around and the + and - keys to change the height of the camera. Also, < and > can be used to bank the view. The engine uses pure high-level routines, so it could be highly optimised. All calculations are made with floating point numbers so, again, this could fly if intended. You'll notice a problem when drawing very close to the camera. This is my main problem.

My intention?  To build a graphic engine that could draw any visual from Stunts at game speed with the same technology (flat triangles), but at any screen resolution. What for?  Could be used to generate high-res images of what a part of a track or replay could look like. Could also be the base for a re-creation of a full Stunts engine. If so, I'd like it to be faithful to the original, only allowing plugins easily. We don't want another Stunts-like game. We want Stunts. In any case, we want a Stunts we can more easily mod. For now, it's just a curiousity. Done the old-school way, but with modern OS and compiler support. Take a look and give any impressions or ideas. Thanks!
Title: Re: Modern system native Stunts proto-engine
Post by: Duplode on September 23, 2018, 03:31:09 AM
Nice work!

Quote from: Cas on September 22, 2018, 11:27:32 PM
I didn't compile it for Windows because I would first have to install a 32bit Linux and then Wine on top and the compiler (I don't know why, but Wine doesn't seem to work with 64bit Linux for me), but I can later get that done and post it too.

You can have a 32-bit Wine prefix on a 64-bit Linux -- cf. the relevant Arch Wiki page (https://wiki.archlinux.org/index.php/wine#Configuration). Below is some stuff that used to be in my .bashrc to help using multiple prefixes, which might be of some use.


# Making wine default to 32-bit.
export WINEARCH=win32

# Keeping the default wine prefix in a non-hidden directory.
export WINEPREFIX="/home/duplode/wine32"

# Simplifying the handling of Wine prefixes.
# (Adapted from http://code.google.com/p/winetricks/wiki/CommandlineTips )
# Of course we will keep some symlinks of our own at
# ~/.local/share/wineprefixes .

prefix-wine() {
    if [ -z "$1" ]; then
        echo "${WINEPREFIX}"
    else
        echo "${HOME}/.local/share/wineprefixes/$1"
    fi
}

lswine() {
    ls $* "${HOME}/.local/share/wineprefixes"
}

with-wine() {
    lswine | grep "$1" > /dev/null
    if [ "$?" -ne 0 ] || [ -z "$1" ]; then
        echo "Please select an actual wine prefix (try lswine)."
    else
        prefix=$(prefix-wine $1)
        shift 1
        echo $prefix
        env WINEPREFIX="$prefix" "$@"
    fi
}

goc() {
    lswine | grep "$1" > /dev/null
    if [ "$?" -ne 0 ]; then
        echo "Please select an actual wine prefix (try lswine)."
    elif [ -z "$1" ]; then
        cd "${WINEPREFIX}/drive_c"
    else
        cd "$(prefix-wine $1)/drive_c"
    fi
}

_lswine () {
    local cur

    COMPREPLY=()
    cur=${COMP_WORDS[COMP_CWORD]}

    if [[ $COMP_CWORD -eq 1 ]] ; then
        COMPREPLY=( $( compgen -W "$(lswine)" -- $cur ) )
        return 0
    fi
}

_with-wine () {
    local cur

    COMPREPLY=()
    cur=${COMP_WORDS[COMP_CWORD]}

    if [[ $COMP_CWORD -eq 1 ]] ; then
        COMPREPLY=( $( compgen -W "$(lswine)" -- $cur ) )
        return 0
    elif [[ $COMP_CWORD -eq 2 ]] ; then
        COMPREPLY=( $( compgen -cf -- $cur ) )
        return 0
    fi
}

complete -F _lswine prefix-wine
complete -F _lswine goc
complete -o default -F _with-wine with-wine
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on September 23, 2018, 03:57:19 AM
I think my problem is more general than just with Wine. I'm having difficulty (lack of knowledge?) getting to install anything that requires 32bit architecture in my 64bit system. When I try to install Wine (which I usually do by using the software centre in Ubuntu or by sudo apt-get install), the installation fails because of dependency problems related to the architecture. Same thing was happening to me with Skype in the past. Now Skype is 64bit-only. So I don't get to the point of having it installed to be able to configure it in any way :(
Title: Re: Modern system native Stunts proto-engine
Post by: Duplode on September 23, 2018, 06:25:34 AM
I don't know if you have already tried it, but you apparently have to explicitly enable alternative architectures (https://unix.stackexchange.com/a/47003/60807). (On Arch, you'd rather similarly have to enable a "multilib" repository.)
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on September 23, 2018, 07:57:13 AM
Looks like it's enabled 32bit, but still even the most fundamental 32bit libraries are not there, so nothing that's 32bit is running. For instance, I'm trying to run the 32bit compilation of Bliss and it just won't. I wonder what I should install next. Probably, I should check with the people at FreeBasic on how to compile 32bit on a 64bit system and that would also allow running most 32bit programs.
Title: Resurrecting 3D rendering. GNU and Windows executables available!
Post by: Cas on June 23, 2020, 01:58:56 AM
Hi!

I was exchanging a few e-mails with Overdrijf and Duplode and my 3D engine was mentioned. I've been taking a look and I found that I initially made it in 2017, but then I modified it in 2019, so I'm going to post it here, together with the 3D object editor, the newer version and with executables both for 64bit GNU/Linux and 32bit Windows/Wine.

Here's what you'll find in the package:
- engine1b is the new engine itself. Source and binaries for both platforms are included. This newer engine is able to open a track file and render the terrain and a small set of track elements. You can freely move and rotate flying on the track. Take a look
- g3dultra is the 3D object editor I used for making the objects you see. It's not super user-friendly, but it does the trick. Objects are not built in a way that's comfortable for the designer, but that makes them optimal for the renderer. More on that below

Here's how you can use engine1b:
- Left and Right arrows to rotate left (counter-clockwise over track's Z) and right (clockwise over track's Z)
- Up and Down arrows to pitch forward and backward like in an airplane
- , and . (that is, < and >) to roll (counter-clockwise and clockwise over viewer's Z axis)
- A, D, W and S to move the camera over the track
- + and - to zoom in and out. This can make things look weird if you forget you're zoomed in or out
- [ and ] to change the FOV. Again, this may make everything look really awful
- { and } to make a render-based zoom instead of a perspective-based one. The most destructive experiment :P

Here's how to use g3dultra:
- Your object is made of verteces, segments and triangles. Segments and triangles are based on the verteces you have in your object. A vertex that's not being used by any segment or triangle is called an "orphan vertex" and shows as a small cyan circle. You start with zero segments, zero triangles and eight verteces forming a box.
- Use the arrow keys to rotate the object. The three axes are always rotated in the same order, so you may experience gimbal lock. Not comfortable, but works and it's the engine that matters in the end.
- Use + and - to get nearer of farther from the object's centre
- These 3D objects are based on layers, like an onion. Higher layers are always drawn last, no matter if they're nearer or father. This allows you to control triangles drawn on top of others and prevents glitches. Use * and / to change the current editing layer. If you go to the previous layer and the layer above is empty, the number of layers in your object will fall back. You'll understand this as you use it
- Use Insert to insert a vertex. You'll have to manually provide the 3 coordinates. Again, not comfortable, but exact
- Use T to create a triangle. Before you press T, you should use the mouse left-button to click on the three verteces in order that you want your triangle to be made of, because T will take the last three selected ones. The triangle will be solid, 2-sided and made of the current colour. The main side, if I remember correctly, will be the one that sees the verteces rotating counter-clockwise
- Use S to create a segment. The same as with T, first click on the two verteces you want to use
- Use C to change the colour of a triangle or segment. You first have to select the triangle or segment. This will also change the current colour
- Use L to change the layer of a triangle or segment. You first have to select it. At the moment of creating them, triangles and segments are placed in the current layer
- Use 1 to make a triangle 1-sided. You have to select it first and if you're looking at it from the secondary side, it will become transparent. 1-sided triangles are very good. They make rendering faster and prevent glitches when it's not clear which triangle is closer to the viewer
- Use 2 to make a triangle 2-sided
- Use ` to change a triangle between solid or partially transparent (like some surfaces in Stunts)
- Use M to create a vertex that's located exactly in between the last two selected verteces
- Use X, Y and Z to split a vertex in the direction of the corresponding axis. Try it and you'll understand it
- Use DEL to delete a triangle, segment or vertex
- Use F1 to start from the beginning, F2 to save, F3 to load, F4 to "un-rotate"
- Use F5 to select a segment. Just hover it and press F5 and it will be highlighted. You can do the same with F6 to select a triangle
- Use F7 to toggle the editor's transparent mode, to see internal triangles and segments more easily
- Use , and . to go the next or previous vertex, segment or triangle
- Use ENTER to type in a command. Commands include FLIP, MOVE and SCALE. Type without parameters to see the syntax
- Use ESC to leave the program
Title: Re: Modern system native Stunts proto-engine
Post by: Overdrijf on June 25, 2020, 10:46:15 AM
I'ver downloaded it now that it's Windows proof. This looks cool!

I don't have anything else to say about it, but I'll try it out more over the next few weeks.

There is no way to convert 3D models from other sources (like Stunts) into the format of this engine, I assume?
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on June 25, 2020, 12:07:01 PM
I've also downloaded it now that it's Windows proof.  ::)
It looks really nice. It has the right atmosphere.

I have played many stunts clones and remakes. and most go banana's with graphics but forget gameplay.
This is nice and clean. If the end result play's like the good old stunts but with better graphics i'd be happy.
other fun stuff can be added later.  (at least, that's what i think  ;) )

I'll try and figure out the object editor when i have some time..

D
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on June 25, 2020, 11:05:21 PM
I will have to study Stunts 3D format more to answer exactly, but in my opinion, converting would be pretty hard because the strategies used by Stunts and by my engine to prevent triangle overlap are different. Still, I imagine I could make a program to transform a Stunts object in its basic form to this format and then, with some manual modifications, it could be adapted. The thing is Stunts also combines 3D objects to make the actual track objects, so it's not easy.

And yes, my idea is to make an engine that looks pretty much like Stunts. Plain triangles. But using whatever resolution one has, so stretching would be polygonal and not by pixel, as happens when you use Stunts in DOSBox. Also, I would add deeper rendering (as can already be seen in the engine), so you could see objects pretty far.
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on June 26, 2020, 07:55:11 AM
Expanding the current engine would be very difficult I imagine. Stunts was built for very limited hardware.
I like the idea behind ultimate stunts. But not the result.
It looks fake and drives like excrement.

But some terrain features are nice.

I'm looking forward to a driving test  ;D 
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on June 26, 2020, 11:05:53 PM
From here to a driving test, it will be long time, ha, ha. To give you an idea, the rendering you're seeing is not nearly optimal. It has to be rewritten and I have only written it this way because it's experimental. Once I get it to do what I want, I'll rewriting, this time knowing what I'm doing. Once I do that, I'll have to deal with things I have ignored for this test, such as transforming objects when they're placed on a slope or possibly allowing different height levels and tracks of other sizes, as well as a background landscape. That will make it even longer for the rendering engine.

But then, the true thing begins, because rendering is only half the work. I have to start from scratch with a physics engine. I still have no idea how I will do that. Only thing I know is what I'm looking for, which is something that feels like Stunts but can be controlled better (for example, that making a car faster doesn't mean that it will produce unpredictable magic carpets or that its gears will behave in crazy ways; that if the car will have powergear, it'll be because the designer wanted it to, not because of a combination of number of gears, grip and weigh of the car resulting in a number that adds up to, say, seven modulo twelve or something like that). Of course, starting from scratch means it's virtually impossible to make Stunts replays compatible with the new project and vice-versa, but as long as they "feel" alike, that's fine for me.
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on June 27, 2020, 07:43:49 AM
Is it possible to work the other way around?.
Built a solid but basic rendering engine with a test track.
Then a (modular) physics engine that rocks.
Then build on the rendering engine.
(Btw, Which language do you use?)

Because if you can't get the physics to work you'll  have an other ultimate stunts..

:o
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on June 27, 2020, 10:12:29 PM
Well, I think building a rendering engine is no easy task in general, so probably, the 3D rendering engine I'm making is arguably the simplest I could go for anyway. And once that works, I can start trying with physics and we'll see what happens. I have to try. And I figure I will have lots of problems, but I don't expect to end up with another Ultimate Stunts, because it seems to me that U. Stunts's physics engine on purpose. You know, we love Stunts, but many people would consider Stunts's physics engine to be very buggy and worth replacing with something more "modern". Maybe that's what the developers of Ultimate Stunts feel. I don't feel that, so my path will be different. I'm not saying I will be more successful... likely not, because it's hard work, but it will be in a different direction.

I'm currently using FreeBasic. I could use something else too. If I had to drop FreeBasic, my next bet would be pure C or perhaps, FreePascal. I don't like OOP and compilers that create huge layers of abstraction. I am also not a fan of third-party libraries. I prefer to write everything myself. I'm not doing it for money, so I like choosing how I do it. But while the compiler is relevant for the renderer (in particular, the graphics library is), for the physics engine, it's pretty much the same. On today's computers, any physics engine will fly, no matter the language. The difficulty lies in making it work well, not fast, as can happen with the graphics rendering. So I believe I'll do fine with FreeBasic :)

The problem I'm facing right now has to do with 3D clipping. I read my code and I've done everything well, only not so tidy, but then I test it and it clearly has some glitches, so I don't know... I'll rethink it and rewrite it. I have the feeling that the next try, it'll work well from the beginning. This is my first 3D renderer, after all!  And then... the physics engine :P
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on June 29, 2020, 10:39:11 AM
I know enough about programing to appreciate the effort, regardless the result.
And i will try to help any way i can.

I have an interesting resource you'll might find useful.
https://www.studystore.nl/p/9783662462201/handbook-of-mathematics (https://www.studystore.nl/p/9783662462201/handbook-of-mathematics)
Quotehis guide book to mathematics contains in handbook form the fundamental working knowledge of mathematics which is needed as an everyday guide for working scientists and engineers.
Quoteemphasis was laid on those fields of mathematics that became more important for the formulation and modeling of technical and natural processes, namely Numerical Mathematics, Probability Theory and Statistics, as well as Information Processing. Besides many enhancements and new paragraphs, new sections on Geometric and Coordinate Transformations

I don't use it because i accepted that learning to program will more time and effort than i can spare.
(this book is not about programing but is part of my C++ , python and Scala book collection)
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on June 30, 2020, 01:17:00 AM
That looks like a great book. The math I'm using in the renderer is actually pretty simple. Rotations are made in the simplest way. The only thing I could do to move further mathematically speaking is go for quaternions and I have a decent idea about how to do it, but yes, I will have to read some more. Still, the hardest technical problems I'm having don't have to do with that, but with the implementation of the math in the programming. In particular, clipping the triangles with the near frustum wall is bringing me headaches and I'm not very satisfied with the horizon generation. It will become more complicated when I want to introduce landscapes, but I feel I will be able to accomplish that.

And then... the physics engine. That'll be hard. I've been thinking on which model I could use. I first considered a rectangular prism, but have since switched to four spheres where the wheels go. This makes the car unstable on its side, like in Stunts and provides some separation from the ground when on four wheels, even if upside-down. It also makes calculations a lot simpler. The prism could still have a secondary role for calculating damage to the car, but not for responding to impact with momentum. If I were to return to my career on Physics, it'd be tempting to create a thesis based on a 3D cars game, ha, ha XD
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on July 10, 2020, 12:05:41 AM
I'm uploading the engine with a few changes. It still has some issues and I will have to rewrite it, but I have started to understand a little bit of why it's not doing as it's supposed to, which will be useful when I create the new one. The cases when the current engine produce artifacts are not so abundant, so it can be used for testing a physics engine anyway.

The ZIP also contains the 3D editor. This one does have more new features, but I would like a completely new one as well. You'll find that you can import OBJ files from Blender or Stressed and also 3SH files from Stunts. OBJ files are more stable and appear to always work fine, but have no colour information. 3SH files are imported with colour, but the palette I'm using is Stunts general palette and apparently, it's very different from the one that's addressed by the 3D objects. Still, seeing the colours helps a lot. Some cars load with a few triangle errors. I have no idea why this happens. And at least one car shape causes the editor to crash. Again, no idea why. But most work. Have a try!

I would like to start a new topic to discuss the project from now on as a game project, including the editor, the renderer and the physics engine. Things like how the 3D format is structured and how it should be, we can all discuss and hopefully, we can start building something together, like... I can program, but ideas and 3D shapes will help a lot. If I don't have to edit and draw, I can concentrate all my efforts on programming. I'll be opening a new topic about it soon so you guys can participate in the project if you feel like. Thanks!
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on July 11, 2020, 09:55:38 AM
I'm really looking forward to this project.

I'm no help programming wise, but 3D modeling I should not be a problem. My semi professional modeling times are 15 years behind me. But I'll manage.

I'm also a visual thinker that sometimes comes up with interesting points  8)

You'll just have to filter out the gem's from the crap...
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on July 11, 2020, 11:03:28 PM
Alright. I was about to open a new topic, but then, seeing this topic is already exclusively for this project, maybe it's better to continue here for now, until it really makes a difference.  Well this is the situation now:

Current 3D engine difficulties
The 3D engine is pretty complete already in the sense that it can draw the elements and you can move around freely. We could start to put attention to other things now, but I do need to fix a couple of things. One that is serious is that the 3D clipping is not working well for triangles that are very close. For this reason, I've been clipping entire triangles, as I can't find the reason. This means that triangles very close, like the track section on which one would be driving may only be drawn partially. This is not acceptable. I think I will just have to rewrite. The other thing is that, occasionally, a large triangle appears and covers a great part of the screen. Again, I can't find the reason, but this happens a lot less frequently than the first problem. If anyone has a hint of why, that'll help, but I assume I'll just have to fix it by rewriting all.

The 3D editor and the structure of 3D objects
3D objects are made in a way that's similar to that of Stunts, but not the same. In Stunts, there are flags per angle to decide whether a polygon is drawn or not. G3D (the way I call my current shape system) does not have this at all. Stunts has two "layers" via a a flag that gives priority to the drawing of some triangles that are coplanar with others. G3D actually defines true layers and you can have virtually as many as you want. This is why you don't need the other per-angle system. Inner layers are drawn first, like an onion. In Stunts, you can make polygons of different numbers of sides, but they have to be convex. In G3D, all polygons are triangles. When loading a 3SH in G3Dultra, polygons are decomposed to triangles. I have still not defined anything like wheels and spheres in this system. G3D files are saved pretty much by copying the structure to the file. I have not optimised that yet. Any ideas on restructuring this would be interesting to read. OBJ files can be read and I could use a differentiation between materials to establish different colour sets, but the editor still does not have that capability.

3D shapes I need to start working
On thing that has been stopping me is the fact that it takes me super long to create shapes and I need them to start making anything out of this engine. The current 3D editor is not comfortable, but if you can edit with Blender o another 3D editor and then export via OBJ and change the colours there, it shouldn't be super hard. What I'm needing first are 1x1 track pieces that are flat. As you see, I have already made the straightways and crossroads, but I need good closed corners. A start/finish line would also be good. Watch the current 3D objects to see about the scale and the details that should look the same. Also, make triangles 1-sided is the side behind is never to be seen. I can make a 2D editor to facilitate this if necessary, then the 2D objects could be copied into the 3D shape as projections or "cyllindrised". If any feature is required for the editor, just let me know too.

First step for physics engine
My idea of the first step is to start making a physics engine in which the car never gets off the ground even partially and is never seen from the outside. You can accelerate and turn and the engine would detect if you're running on pavement, dirt or grass and if you crash into a solid object. Air drag would increase with speed, ground drag would happen depending on the ground material. Engine power would create force and the car mass would translate it into acceleration. Break power would work similarly with inertia. While turning, the normal component of speed should turn to virtual centrifugal force that would compete with tyre grip and ground material grip. This is going to be hard. I don't know how to cause the car to naturally lose control when the force exceeds grip... I can't make it just continue forward and I fear I will have to do some per-wheel calculations. If grip is enough, this would cause the car to bank slightly while turning. Achieving all this will take pretty long, so let's assume we won't be seeing ramps for months.

Car and track formats
As this will be very simple from outside, I'll have to create a very basic car format in which we'll enter the car parameters and there will be no car shape at first. For easy testing, this would be a simple config-file-style format with equal signs for the parameters. For the track, Stunts tracks can be loaded and unknown objects not rendered. Additionally, another format can be created so that tracks can have sizes other than 30x30, but that's about it. These files should better be a simple binary representation of the contents of the track, such as width, then height, then a single layer with the elements one by one, or something like that.

All opinions are welcome
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 01, 2020, 06:11:18 PM
Is your engine opengl based or do youwrite your own software renderer?
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 02, 2020, 02:39:04 AM
I'm writing my own software renderer. I haven't learnt to used OpenGL yet. It'd be interesting for the future. But right now, I really want to do this in software. In part, because I want to learn how to do it from scratch and feel I've done it all myself, but also because I know it won't be demanding, so it will run very fast even in software. I may be mistaken, but I think it is necessary to use 3rd party libraries to access OpenGL functions, so software rendering also means more portability and that somebody who's not familiar with any library can still understand the code because all is there.
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 02, 2020, 08:19:09 AM
Doing it from scratch is a funny thing i really hope to see someday the fully original stunts engine with all the quierky optimizations without using floating points, there are only a little bit matrix, vector calculations seeable in restunts sources

Doesn't come freebasic with builtin opengl support?

I think its easier to use opengl for an engine that is so less demanding, portability is not a problem with this >30 years old standard, there are even pure software implementations available like mesa3d, i think its easier for others to understand opengl code, and there are still some textures to render, background, tunnels i think


Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 03, 2020, 06:50:12 AM
Yeah. To be honest, I have barely read anything about OpenGL works, so it's more what I don't know than what I know. I really do want to learn more about it. And yes, I want to do this first from scratch because, well, it's a simple plain-triangle-based renderer, so it's not too crazy for the experience of doing it like in the old times, but for more complex engines and for future versions of this one, maybe, I definitely would consider learning OpenGL and trying it.

I was poking around one day, trying to find out what OpenGL was all about and I did see there were some include files for FreeBasic, but I didn't put much time on analysing that, so I can't say much about it. I've heard about OpenGL for a long time already, you're right. I didn't know that it was possible to get software implementations of it.

Currently, in my renderer, I'm using floating point numbers, but I'm doing that because it's not opitmised. Once it works, I can switch to fixed-point math and assembler-drawn triangles to make it run faster, although I'm surprised about how fast it already works considering it's so much non-optimal code!  The guys at FreeBasic forum suggested at some point I should not use fixed-point math, that it's a thing of the past, etc. Some people say the same about assembly language. I don't know... I suppose it depends on what you feel like doing today, ha, ha.... as long as it works and you enjoy doing it!  But yes, most options, I'd like to try them.
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 03, 2020, 09:55:49 AM
Quote from: Cas on August 03, 2020, 06:50:12 AM
Currently, in my renderer, I'm using floating point numbers, but I'm doing that because it's not opitmised. Once it works, I can switch to fixed-point math and assembler-drawn triangles to make it run faster, although I'm surprised about how fast it already works considering it's so much non-optimal code!  The guys at FreeBasic forum suggested at some point I should not use fixed-point math, that it's a thing of the past, etc. Some people say the same about assembly language. I don't know... I suppose it depends on what you feel like doing today, ha, ha.... as long as it works and you enjoy doing it!  But yes, most options, I'd like to try them.

there is a real need to use opengl, floating point and NO assembler if you want to make the engine public available and useable for others
everything else is just too much a thing of the past - also completely ignoring the not that-optimal (opcode)code that the freebasic compiler generates :)
(buts its still able to generate dos executeables - but there is also a gcc 10/djpp version that can be used for 32bit dos executables :) - but you seem not to be a C/C++ fanboy)

but still a good tutorial for from-the-scratch maker like these videos:
Code-It-Yourself! 3D Graphics Engine Part #1 - Triangles & Projection https://www.youtube.com/watch?v=ih20l3pJoeU (https://www.youtube.com/watch?v=ih20l3pJoeU)
Code-It-Yourself! 3D Graphics Engine Part #2 - Normals, Culling, Lighting & Object Files https://www.youtube.com/watch?v=XgMWc6LumG4 (https://www.youtube.com/watch?v=XgMWc6LumG4)
Code-It-Yourself! 3D Graphics Engine Part #3 - Cameras & Clipping https://www.youtube.com/watch?v=HXSuNxpCzdM (https://www.youtube.com/watch?v=HXSuNxpCzdM)
Code-It-Yourself! 3D Graphics Engine Part #4 - Texturing & Depth Buffers https://www.youtube.com/watch?v=nBzCS-Y0FcY (https://www.youtube.com/watch?v=nBzCS-Y0FcY)

asm or fix-point float is only needed if you want to support systems of the age of stunts itself (<= 80186) - every Pentium1 class cpu can easily handle the math and drawing of stunts demands in software without any inline asm - todays cpus are just dying in agony while waiting for the user input - if the generated code is not too bad :)
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 04, 2020, 01:48:07 AM
About OpenGL
As I said, I like it and I'm insterested. I am only not using it now because I want to first do this all myself, but I will get to it later. One reason I would consider for not using it, that is, on purpose, would be if I want to make something DOS-compatible. This project, I may make it so. Otherwise, I'd go for OpenGL. There's also the option of making both possibilities available, but that's extra work.

About assembly language
I am a fan of assembly, yet, I'm aware that sometimes, it's not a good idea to include assembly in your projects. It all depends on which platforms you're targetting and which public... in particular, if you want to make the source code usable for derivatives to other people.  But assembler does not interfere with this if you use it well. For example, in a project I made some time ago, I used assembler for a font blitting routine. The main program would call this routine to get extra speed when writing lots of text on the graphics screen, but you could also use the internal text drawing function at your option. Then you had a program that was both as fast as possible and as portable as possible. On the other hand, sometimes, I really don't have any interest in non 80x86 or AMD64 based processors, so using assembly does no harm. Of course, I have to know when it makes sense to use assembly or not... but the truth about assembly is always the same: it's super fun to play with and it produces very fast and small code if used well.

About floating point math
Honestly, I'd like to never have to use fixed-point math, because it complicates the programming, the editing of the source code and opens the doors for lots of bugs. I would only use it if my target platform needs the optimisation for the speed required. A 386-based computer, for example, would often include the 387 FPU, but for a game, it wouldn't make sense to use it. It'd be too slow. This project, I expect, won't need a switch to fixed-point math.

About C/C++
I don't like C++, but I do love C in many aspects. In general, I think OOP is a mistake. Many programmers, much more experienced than I agree with me on that. But about C, there are only a few reasons why I prefer FreeBasic. Namely:

1 - C does not support graphics. You have to include a 3rd party library
2 - I dislike the concept of having to include a header file to be able to use a function that's already part of the language
3 - Different compilers have slightly different rules, so the code is not 100% transparent between platforms
4 - I don't like the way most C programmers code in C, like using dedicated types when a standard type could be used

Only 1 is a serious problem. I can simply ignore 2, I can stick to GCC for 3 and I can just work on my own code for 4. I know that some libraries, such as SDL, are very popular and cross-platform, but not being part of C itself, they tend to pose restrictions I don't like. For example, SDL does not support DOS, is thread-based (so I'm forced to using its threads instead of creating threads only when I want to) and it's designed in a OOP style, which I dislike very, very much XD  I've been thinking of using C accompanied with FreeBasic's graphics library, which is free software and was written in C. Them I would of course, include the source code for the library with my code, because I don't like people having to go to third parties to be able to compile my code. But I don't know.... Any recommendations, I'll be happy to read about :)

About the tutorial
That's super, super interesting!  I'm going to check it right away!!
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 04, 2020, 07:14:47 AM
Quote from: Cas on August 04, 2020, 01:48:07 AM
About C/C++
I don't like C++, but I do love C in many aspects. In general, I think OOP is a mistake. Many programmers, much more experienced than I agree with me on that.

OOP can be evil - a well known (in business) aspect of C++

Quote from: Cas on August 04, 2020, 01:48:07 AM
But about C, there are only a few reasons why I prefer FreeBasic. Namely:

1 - C does not support graphics. You have to include a 3rd party library
2 - I dislike the concept of having to include a header file to be able to use a function that's already part of the language
3 - Different compilers have slightly different rules, so the code is not 100% transparent between platforms
4 - I don't like the way most C programmers code in C, like using dedicated types when a standard type could be used

my background is 30 years in C/C++/Scripting/Asm..., Multiplatform delevopment (Windows,Linux,Embedded/VxWorks,...), Backend/2D/partialy 3D/Reverse Engineering and Project managment in 500k-2Mio Lines of code projects, with 5-30 Team members, working with +10-20 third parties, using different make tools and different development environments, using several different compilers

i understand your 4 statements (deep in my heart), but none of them had any relevants in my daily business - because you can't have always the best solution integrated - the market is too fast moving, too feature demanding - that can't be integrated into a single language - that is the reason
the world outside your lone-wolf-styled isn't that evil - third parties are a need and will be forever - and they mostly do not complicate projects - its just a part of the whole and i've never got problems with most of the third parties, build Qt or some compilers yourself or look at the 30GBs!!! of C/C++ Libs of the Amazon AWS and you will see that your concerns are just 0,00067% of my problems :) - the third parties are a thing at starting the project but becoming irrelevant if it reaches the multi-thousand lines of code stage

most C/C++ compilers are nowerdays on par - the difference are much much smaller then 5 years before, SDL is a pure C style api and useable per DOS-Extender under DOS
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 04, 2020, 09:05:56 AM
The last time I tried to use SDL, I remember there was some function that you had to run and it locked your program there. And then, with another task, you had to interact with the instance that had that blocked function. Maybe that's not the only way of doing it. If I can use SDL unlocked and without any OOP, I might consider it.

My experience with programming is entirely different from yours. I never programmed as a job. It's always been my hobby. I started around 1991 and I learnt it all by myself. Always programmed alone although, a few times, I did plan the programming with a friend of mine. I've always liked doing the whole thing myself. I have had moments in which I tried to read other people's code mostly to find out how the handled something I didn't know, such as producing sound with the AWE64, ha, ha, but it's always been really hard for me to read other people's coding.

I started with QuickBasic on DOS. Then tried Borland C++, although I always used it as a C. I also did try Turbo Pascal, all real mode DOS. When Windows became the most popular OS, I didn't like it. I continued using DOS as my primary OS and had another partition with Windows 95 only for accessing the internet (and burning CD ROMs, as I didn't have a program to do that for DOS). Around 2005, I was able to get a computer running Ubuntu and connecting to the internet. From then on, I quickly moved to GNU-only and sometimes DOS, as a hobby. I have made some incursion in web stuff, like PHP scripting. I don't love it, but it's reasonably "nice" compared to most scripting languages. But I'm mostly an offline programmer. Because I'm not paid, I get picky and like doing it my own way. Why not?  I've got no boss!  And I tend to always say what I don't like, which annoys some people, but don't get me wrong, when people come and tell me about their own views, I do get very interested. I don't reject other ideas.

And yeah, FreeBasic is not perfect either. It's super transparent, but it's got its shortcomings. I just haven't found any option that I feel more comfortable with. But many times, I think I should try to use GCC more often because it's a lot more broadly used and understood. And I'd like it to have some graphics system that were standard and simple, because SDL is too big a thing for simple programs.
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 04, 2020, 11:06:25 AM
Quote from: Cas on August 04, 2020, 09:05:56 AM
The last time I tried to use SDL, I remember there was some function that you had to run and it locked your program there. And then, with another task, you had to interact with the instance that had that blocked function. Maybe that's not the only way of doing it. If I can use SDL unlocked and without any OOP, I might consider it.

most frameworks do this "you-need-to-implement-this-function" beeing able to compensate the platform differences - you will come mostly to the exact same code when not using FreeBasic that wrapps that part of the code aways from you (but still not capable to do all needed needs for development in business - C is more complex - but mainly because of more needs)

Quote from: Cas on August 04, 2020, 09:05:56 AM
And yeah, FreeBasic is not perfect either. It's super transparent, but it's got its shortcomings. I just haven't found any option that I feel more comfortable with. But many times, I think I should try to use GCC more often because it's a lot more broadly used and understood. And I'd like it to have some graphics system that were standard and simple, because SDL is too big a thing for simple programs.

you are just not used to other languages and never in a year long situation that third parties are a must - thats it :)
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 05, 2020, 12:18:41 AM
Hey, and what about OpenGL?  I mean, if I use OpenGL, does that replace the graphics library or do graphics libraries like SDL implement on OpenGL?  Say I make a program that works graphics directly through OpenGL and nothing else... can I make my program a "portable binary"?  I like making my programs so that you can compile the source code, but you don't have to do it to get it to work.

And back to this project... I'm making advancements. I am rewriting the engine in a cleaner way and I found an important "bug" and got it fixed. It'll soon be running the basics and I would like to give the project a name and start moving forward. Maybe it deserves a new topic once the code can begin to run. I've been thinking of project names such as:
- Stunts beyond the fence
- Powergear (yep, why not adopt the good-old term, as long as it isn't somebody's trade mark?) :P
- FreeWheel (a pun to Free Will and also to free software)
- The Fellowship of the Wheel
- Or better, something imaginative and a lot less stupid than the ones I've just listed XD (though Powergear does sound good)
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on August 05, 2020, 09:21:15 AM
I like powergear. it is in use though, but it's not likely to be a problem. https://powergear.eu/ (https://powergear.eu/)

I was thinking in the line of "Stunts Legacy.
From the player's of Stunts a.k.a. 4D Sports Driving"

I thought of it because my earlier suggestion of a legacy driving mode next to simulation.
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 05, 2020, 10:22:06 AM
StuntsLegacy for the game - but only if it gets ready
StuntsLegacyEngine - project working name
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on August 05, 2020, 02:24:37 PM
Time for some bad premature fan art  8)
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 05, 2020, 03:02:06 PM
just wow
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on August 05, 2020, 04:18:21 PM
Quote from: llm on August 05, 2020, 03:02:06 PM
just wow
Haha, thanks. But I can do much better  8)
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 05, 2020, 11:10:54 PM
Hey, that sounds good!  With the actual meaning of the word (as nowadays many people use "legacy" to mean "old", but that's not what it means). Also, my "Beyond the fence" could be a subtitle used sometimes.

And I like that about giving the engine itself a more specific name :)  I could rename this topic or start a new one. I feel more like starting a new one, because the engine starts to take shape and I'd like to:

- Place a web address from which you could download the project or contribute to it
- Have a starting post with the details on the current status of the project

I have a notabug.org account where I've uploaded Bliss. I am not accustomed to using version control, but I could either start learning or I could just use it in its most basic form to exchange the code and that's it. I could even make my own contribution site if it became more comfortable, anyway... I can do some PHP, but I think it'll be OK with this forum plus notabug. The thing is that this project will require a lots of exchanging data files such as 3D models, tracks, etc., not as much as the code itself. The forum allows for file exchange, but too much of it would not be good for the server... This is a forum after all and main purpose is communication, not file exchange. And version control is good for exchanging source code, but again, not for data files. What would you guys suggest?
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on August 05, 2020, 11:31:25 PM
Maybe an FTP for file management. E.g. ftp.stunts.hu and only accessable for (selected) forum. members??
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 06, 2020, 04:32:16 AM
Uhm... Well, for now, I uploaded it to the repo. In any case, we can use e-mail, but a data file shared storage space would be great. I'll create the new topic
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on August 06, 2020, 09:01:19 AM
Quote from: Daniel3D on August 05, 2020, 11:31:25 PM
Maybe an FTP for file management. E.g. ftp.stunts.hu and only accessable for (selected) forum. members??
Or a Gmail project email, then we can use Google drive for file's.

EDIT: maybe a good starting point. We can always move the data.
And it's easy to set different read, write and modify rights.
Title: Re: Modern system native Stunts proto-engine
Post by: llm on August 06, 2020, 09:46:41 AM
the engine/game needs to be in a more useable/playable state before make the big web and community stuff - for now i think the forum/and his is way enough
most development usually happens privately between interessted developers

todays development is done on github/gitlab - everythings free, including web-hosting, compiler-farm etc. most open source projects are on any of these two

but i say: if you keep it based on freebasic you will not get any of the active coders in this forum - because all of them - including me using C/C++ :)
Title: Re: Modern system native Stunts proto-engine
Post by: Daniel3D on August 06, 2020, 09:55:33 AM
I won't be of much help programming wise anyway.
But I am a decent (albeit very rusty) 3D modeller and have graphic design experience.
Title: Re: Modern system native Stunts proto-engine
Post by: Overdrijf on August 06, 2020, 11:19:16 PM
Since the other Powergear is some fancy lights for your kitchen brand we could still use that name for a racing game. Freewheel sounds pretty cool too.

I have some sort of an instinctual problem with any name containing "Stunts" as in Stunts Reloaded Stunts Legacy New Stunts Stunts 2020 etc. It kind of pidgeon holes the whole thing as a fan/sequel project. It brings people in who are looking for the next Stunts, but it does not project as much of its own separate draw maybe. While if you have something just slightly further away from it, even if it's just Stuntland (or something that doesn't sound as silly, like Stunt Island but that is already a game) that seems a bit less married to the idea of being Stunts. That said: since we're literally recreating Stunts assets maybe distance is something we absolutely do not want, maybe the closer names are better.

Also, yeah, hi. I haven't posted here a lot, but I've been involved in some behind the scenes talk about tracks and editors. I also have a bit of 3D modeling experience. It's not advanced, because it was all done for Stunts, but for this project that's in the right ballpark. I've done some programming in the past, but, well, suffice it to say that most of that was on a calculator, and most of the little that's left was for technical study related applications. So I don't really get a vote in which language is better.

Anyway, the actual point of this post was: nice to see a few relatively new people/folks who I hadn't run into a lot contributing on this project. Good technical discussions!
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 06, 2020, 11:26:03 PM
I created the new topic. Uhm, you may have read in other posts that I'm not a friend of Google, Facebook, Microsoft, Apple, etc. I prefer to avoid them as much as possible. But no problem, there are other drive options and I can even create my own if necessary. And GitHub is Microsoft, but I have NotABug. Still, I agree, the forum and e-mail are OK at this point. Later, we'll see.

I want to do this in FreeBasic firstly because I am also part of the FreeBasic forum and if I get a working game made in FreeBasic, it'll attract the people from that forum and not just from this one. It might even bring more people to the Stunts community :P  Secondly, I would really like to do it in C, but if I start that now, that will slow down the process considerably, as I will have to go back to finding a good way to provide graphics and other problems that are already solved for me with FreeBasic. Yet, once I have a working engine, it'll be easier for me to just translate it to C and then, it can be modded and extended.

For the moment, what I need the most is the modelling and ideas. Programming... maybe I wouldn't be a good team member, as I have my own style and don't like changing it. Like, I never use "int" unless the function requires it because they're essentially a 64bit variable of which you're only allowed to use 32bit. So I go for "shorts" and "longs" instead. I'm sure many people wouldn't like that. And I don't use the lowerCaseStartingCamel variable name format.... It looks too "Javish" for me :P  I think other programmers would have a headache with me. But I don't know XD

Oh! You guys posted while I was typing... Well... I'll read that now :)
Title: Re: Modern system native Stunts proto-engine
Post by: Cas on August 06, 2020, 11:37:22 PM
Overdrijf!  Nice to have you here!

And yes, I also get that feeling about using the word "Stunts" in the name. I figure it's OK for the engine project, but probably the final game should have some other name. I have created the new topic already with the name StuntsLegacyEngine. Even that can be changed, but I had to give it a name for now and Powergear or Power Gear is something I like, but I think, should be discussed with as many members of the community as possible because that name kind of belongs to all of us, so I didn't want to hurry up to take it.

Now that we do have some code to work on, that is, you guys can already make models and try them with that code and can also see the code and make some changes and tests if you want to and seeing more or less what it contains, can also give ideas, I suggest that we move to the other topic. I think this one was more on the previous, more experimental engine.