+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Prolific Programmers (https://qb64phoenix.com/forum/forumdisplay.php?fid=26)
+---- Forum: MasterGy (https://qb64phoenix.com/forum/forumdisplay.php?fid=45)
+---- Thread: Monster Truck (/showthread.php?tid=4430)
RE: Monster Truck - MasterGy - 02-07-2026
In basic of course.
I don't know any other languages. I've always wanted to be able to make a small application for android, but unfortunately I only know basic. I found B4A. (basic for android).https://www.b4x.com/
At first it was difficult, but later I realized that it's a very good editor, a well-transparent system, object-oriented, uses multiple 'timers', runs on multiple threads, is fast, and syntactically it's the same as QB64. When I got the hang of things, let's do something 3D! But unfortunately there's no such convenient, easy instruction as _maptriangle here. I was never interested in opengl, but I had to learn it. And then the ideas came:
2d opengl
https://www.youtube.com/watch?v=2PIgOF07BvE
3dopengl
https://www.youtube.com/watch?v=V81sO6SqKmw
3d opengl, also with VR glasses (two opengl windows with angle deviation)!
https://www.youtube.com/watch?v=xy3gdXoIOcs&t=22s
https://www.youtube.com/watch?v=9zD7TynEigc
raytracing
https://www.youtube.com/watch?v=qPOHzZcuBLA
After that I tried out what I learned about opengl on QB64.
https://qb64phoenix.com/forum/showthread.php?tid=3774
I wrote this so you can see that every program I showed you is BAD!
You showed me the revolutionary breakthrough, the professional approach with GLLIST. Because I didn't use vbo in openglSE. It doesn't know gllist either. I didn't know gllist either, because I didn't encounter it in opengl SE. In fact, all Android programs should be rewritten to use VBO. Because the performance is noticeably poor. They run at 60fps on a modern phone, but they are not well optimized and just eat up resources.
RE: Monster Truck - hsiangch_ong - 02-10-2026
clarify it's the program. indicated in the first post of this topic. this was written before i noticed the other program.
neat program! great job as always.
fun to be able. to change to front, rear and all-wheel drive on the fly. yet at the "corners" of the terrain. i easily get the car like dying cockroach. the car difficult to steer without its getting "upset." but it jerks around in good fun.
RE: Monster Truck - MasterGy - 02-10-2026
(02-10-2026, 12:45 PM)hsiangch_ong Wrote: clarify it's the program. indicated in the first post of this topic. this was written before i noticed the other program.
neat program! great job as always.
fun to be able. to change to front, rear and all-wheel drive on the fly. yet at the "corners" of the terrain. i easily get the car like dying cockroach. the car difficult to steer without its getting "upset." but it jerks around in good fun.
you have perfectly pointed out the main problem: the car is uncontrollable. I am working on this to make it enjoyable.
thanks for trying it out!
RE: Monster Truck - hsiangch_ong - 02-12-2026
i tried the example. offered in post #7 of this thread.
https://qb64phoenix.com/forum/showthread.php?tid=4430&pid=39705#pid39705
@MasterGy
never cease to amaze how fabulous! it was fun seeing a compact car. very well recognized in the u.s.a. with good detail. i visualize the actual model. without the oversized wheels. thank you for the model of 1980's honda civic.
it might be a problem on my side. (i'm on linux operating system.) or i don't know if it was already mentioned on this topic. must take it easy with accelerating. after about five minutes driving around. the program becomes confused. the front wheels spin against "forward direction." no matter what is the "drive style" that is set.
i can't explain this clearly enough in words only. i used a jpg file i created. for the racetrack. to simply drive around. set height to a rather low value. so it doesn't catch on the sensitive wheels and suspension so much. press and hold up-arrow key. for long enough. it seems to go at a maximum speed. cannot steer also. because it's dangerous to do it on a real car. otherwise in this program. i hit a "hill" with the wheels and suspension. then the car decides to mess up. with its front wheels as i've already mentioned.
i had to edit the jpg file. to create a "giant plaza" in the middle of the racetrack. (bottom right corner of grey shaded area.) otherwise i sought a way. to change a bit. the starting position of the car. this was the image. before i edited it.
one thing i forgot to mention. it must be because. i changed the dimensions of the car a bit. made wheels smaller and closer together. put the wheels closer to the chassis. maybe with "default" values. the "drive" doesn't get confused.
RE: Monster Truck - MasterGy - 02-17-2026
Huge space, manual shifting, the car is more agile (more nimble), better road holding, less calculations.
The program works for about 1 minute when it starts, but it saves the generated track (which is almost 1GB), so the next time you start it, it takes less time to load.
If you roll over, you don't have to start over, with the K-key you give a lift to the front wheels, and thus the car can be tilted back.
There is also a 'game' mode. if you press the G-key, you will see 5 balls on the radar. You have to catch these.
I added mouse control. since steering in real life is an analog thing, it cannot be solved precisely with buttons. (either I steer left or right ??? this is stupid in real life) You can also control it with the keyboard, in the traditional way, or you can steer by moving the mouse left and right. left button forward, right button maybe. both buttons = handbrake.
The control requires skill and speed, I recommend manual shifting, so you can immediately control the torque if the car wants to slide off the road.
If you want to roll over, smaller wheelbase. If you want to go stably on hills, larger wheelbase. The physics is implemented on the screen with approximate accuracy.
Track editing works the same way. The BLUE channel is the depth data. If the RED channel =255, so it is red on the map image, the program covers it with asphalt.
It can be easily edited with an image editor. Any image. If we want a smoother surface ? 'blur'. If we want to shift and scale the level differences ? 'bright/contrast'. Do we want a lot of potholes ? 'add noise'.
I hid the QB64 logo in one part of the map.
If you want to experiment with your video card's capabilities, try this: at the beginning of the source code you will find: MapDat(1) = 2000. It is currently set to 2000. This means that the entire map has 2000x2000 depth data. The higher you set the value, the higher the resolution it works at. I think this is already a huge resolution.
Important! The game can be enjoyed if the physics are 27,28,29,30FPS. This can be seen above. On a slower computer it may be less, but unfortunately then the game will not provide the experience I calibrated it for.
hsiangch_ong:
Thanks for your answer. The civic in the game is a very underscaled, dumbed-down model. If you want the original (with wheels, in high resolution, complete), I will be happy to send it to you. I don't have Linux, I can't test it. Are the physics good? I didn't answer in detail because I rewrote a lot of things, so I hope that the errors you noticed have been corrected. I hope you try this too, and now you can compare it to what.
An afterthought.
This is an exciting area of flexible body physics. It is very easy to model the operation of any structure. But unlike rigid body physics, it requires a lot of calculations. I spent a lot of time just calibrating it. This car game is a very deceptive and simplified pseudo-physics. Inaccurate physics. The relationship between flexible points can describe the structure of a cube, a car, a clockwork, anything that moves, has an axis, can be attached to something. Here, the most accurate result would have been if I had given the movement from the engine crankshaft all the way through the differential, to the axle of the wheels. This is conceivable, but it's crazy. And a lot of calculations. Currently, the torque is applied to the outer surface of the driven wheels. And since there is no counter-force, the car does not rise. In the game, it rises, but I achieved it by cheating. It would be very nice to implement the dynamics of a complex structure someday, but for now I want to finish this car game.
https://drive.google.com/file/d/1JUOWDKNskLm-qTJWEtQJOMe3eCVbuUc4/view?usp=drive_link
RE: Monster Truck - Unseen Machine - 02-18-2026
Getting there mate and the interface looks much more professional!
As for the terrain, use two maps one for the terrain and one for the road and then SPLAT (thats whats the method is actually called!) the road onto the terrain.
Create one master texture for the entire map and then you dont need to have repeated calls to glbindtexture for each vertex.
And as your making huge environments, try breaking it down into sections, say 64 * 64 and then create a gllist for each section and with frustum culling you then only render whats actually visible.
Those 3 tips will get you back to 120 fps easy!
I'd give you my latest work on terrain but its c++ so not sure itd be helpful.
Keep up the good work though!
Unseen
RE: Monster Truck - MasterGy - 02-18-2026
(02-18-2026, 04:31 AM)Unseen Machine Wrote: Getting there mate and the interface looks much more professional!Thanks! My program works similarly to what you described. Yes, I first ran into the error that too many glbindtextures slow down performance.
As for the terrain, use two maps one for the terrain and one for the road and then SPLAT (thats whats the method is actually called!) the road onto the terrain.
Create one master texture for the entire map and then you dont need to have repeated calls to glbindtexture for each vertex.
And as your making huge environments, try breaking it down into sections, say 64 * 64 and then create a gllist for each section and with frustum culling you then only render whats actually visible.
Those 3 tips will get you back to 120 fps easy!
I'd give you my latest work on terrain but its c++ so not sure itd be helpful.
Keep up the good work though!
Unseen
What happens is that, at the beginning of the program:
MapDat(0) = 1900 'this determines the 'world size' of the terrain. The size of the car is the default size. The entire terrain can be made as small as a speck of dust on the screen, or so large that it takes 2 hours to drive across.
MapDat(1) = 2000 'this is the resolution of the terrain. The resolution of one side of the terrain. The entire terrain in this case is 2000x2000 height value. It is recommended to create the depth-texture relief image file accordingly. In this case it is 2000x2000 pixels, and each pixel will be 1 height point.
MapDat(2) = 2 'this determines how many textures I use. currently 2. grass, or asphalt.
MapDat(3) = 100 'height relative to the world size (mapdat0). This is important for calculating normals. (It has nothing to do with collision checking, that is done differently)
MapDat(4) = 10 'divides the terrain into this many different blocks. currently 10. so 10x10.
And then here comes what you say. Based on the example, the program creates 10x10x2 gllists. Each block is created as many times as there are different textures. In this case, 2. This way I avoided many glbindtextures. The data of the blocks (vertex, normal, texture coordinates) is saved in files. Separately for grass and separately for asphalt. So what you said: 1 texture = 1 gllist. It creates 10x10x2 files (about 1 minute), which is almost 1Gbyte at this resolution. The next time it starts, it only loads these (about 10 seconds)
And the blocks are drawn like this: Where you are: "A"
Code: (Select All)
JKLMN
YBCDO
XIAEP
WHGFQ
VUTSR
How can it be 120Fps? It can do a maximum of 60fps for me under qb64.
I'm interested in what you're doing, but based on the c code I'm not sure I'd understand it.
RE: Monster Truck - Unseen Machine - 02-19-2026
So i think as we are aligned in most of it the 1GB thingy....mate youre over cooking and over complicating it! My BSP and with models is < 10mb ram when i port it to AZDO mode itlll be < 8 so i think youre missing a trick or dont truly understand the basic principle's yet. Like that level of memory usage is for Unity and Unreal, not a basic fronted simple terrain engine!
Yes you can hack it to suit your needs but there are much faster and better methods!
Dont take this as me saying its crap, i love you and your work! I will make a stand alone version of my terrain engine that you can then use and add your car too and then I hope i can teach you something!
I can do >600 fps with my system atm!
John
RE: Monster Truck - MasterGy - 02-19-2026
(02-19-2026, 12:45 AM)Unseen Machine Wrote: So i think as we are aligned in most of it the 1GB thingy....mate youre over cooking and over complicating it! My BSP and with models is < 10mb ram when i port it to AZDO mode itlll be < 8 so i think youre missing a trick or dont truly understand the basic principle's yet. Like that level of memory usage is for Unity and Unreal, not a basic fronted simple terrain engine!You can store the terrain information in a smaller space, but this is the fastest way I could solve the loading.
Yes you can hack it to suit your needs but there are much faster and better methods!
Dont take this as me saying its crap, i love you and your work! I will make a stand alone version of my terrain engine that you can then use and add your car too and then I hope i can teach you something!
I can do >600 fps with my system atm!
John
How can you load the gllist faster than this?
I could save on file size if I used drawarrays/drawelements, but for some reason that doesn't work well in gllist.
How can you solve the loading faster than this?
I'm curious about your solution.
Code: (Select All)
Open TFILE$ For Binary As #FF
GLlistMAP&(tx, ty, Atext) = _glGenLists(1)
_glNewList GLlistMAP&(tx, ty, Atext), _GL_COMPILE
_glBindTexture _GL_TEXTURE_2D, text&(Atext)
_glBegin _GL_TRIANGLES
If LOF(FF) > 2 Then
ReDim dat(LOF(FF) \ 4 - 1): Get #FF, , dat(): Close #FF
vertCount = UBound(dat) + 1
For i = 0 To vertCount - 1 Step 8
_glNormal3f dat(i), dat(i + 1), dat(i + 2)
_glTexCoord2f dat(i + 3), dat(i + 4)
_glVertex3f dat(i + 5), dat(i + 6), dat(i + 7)
Next i
End If
_glEnd
_glEndList
Close FFRE: Monster Truck - MasterGy - 02-22-2026
even better physics, and many small improvements.
https://drive.google.com/file/d/1sc5DCnV_GhX5waXGILLFF9XNu66Sl5ra/view?usp=drive_link