News:

Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu

Modern system native Stunts proto-engine

Started by Cas, September 22, 2018, 11:27:32 PM

Previous topic - Next topic

Cas

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!
Earth is my country. Science is my religion.

Daniel3D

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...
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts
---------
Check out the STUNTS resources on my Mega (globe icon)

Cas

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
Earth is my country. Science is my religion.

llm

Is your engine opengl based or do youwrite your own software renderer?

Cas

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.
Earth is my country. Science is my religion.

llm

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



Cas

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.
Earth is my country. Science is my religion.

llm

#22
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
Code-It-Yourself! 3D Graphics Engine Part #2 - Normals, Culling, Lighting & Object Files https://www.youtube.com/watch?v=XgMWc6LumG4
Code-It-Yourself! 3D Graphics Engine Part #3 - Cameras & Clipping 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

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 :)

Cas

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!!
Earth is my country. Science is my religion.

llm

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

Cas

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.
Earth is my country. Science is my religion.

llm

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 :)

Cas

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)
Earth is my country. Science is my religion.

Daniel3D

I like powergear. it is in use though, but it's not likely to be a problem. 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.
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts
---------
Check out the STUNTS resources on my Mega (globe icon)

llm

#29
StuntsLegacy for the game - but only if it gets ready
StuntsLegacyEngine - project working name