Messages

I will change the code to integers and check the results.

In summary, I broke my head to give you an example that works with floats for nothing 
Too bad, I'm sure it could have been the beginning of a beautiful library specifically dedicated to this type of games with for example sprites by layers, sprites moving between each layer, ... 
A kind of 2.5D graphic engine

Really sad news about Bak...

Thank you for him 

[R.I.P Master]

Unfortunately, this does not solve the problem of tremor with floating values.
In fact, the only way in opengl is to create a pseudo-3D.
Here is an example that is easily adaptable (and maybe, can be transformed into a real library).
Sorry if I didn't comment more, I did it tonight and I'm a little tired (also sorry if the code is not very clean).

Use "+" or "-" to speed up or slow down scrolling.

I take this comment to salute the memory of Steve Bak who left us last month... in almost total indifference
He was the king of scrolling on Atari, vertically (Goldrunner), horizontally (Return to Genesis) and horizontally with parallax (StarRay).

R.I.P Master...   ...   


http://atariage.com/forums/topic/288000-rip-steve-bak/

Too bad 
With my solution, I totally solved my problem, even if yours is not quite the same, try anyway because I don't think it's a GLB bug, I think is one of the reasons why there is always an option in a 3D game to control the sensitivity of the mouse 

[--- EDIT ---]

Yes, it's not so strange

Here are some reasons:
1 / We can only assign one texture per object (it's also a problem for the lightmapping).
2 / You have implemented a frustrum optimization by object (thanks, needless to do it), so it's interesting for speed.
3 / For example, games like Minecraft require a lot of objects.
4 / Moreover, what is important for the speed (and the memory) in Opengl is not the number of objects but the complexity of each object.

But rest assured, on the maps where I need more, I will assign them on the fly (I hope without much slowdown).

Thank you for your interest and long life to GLB on Steam 

--- EDIT ---

Hmm ... after Gernot's intervention, I thought about it and maybe I was wrong.
I'm looking for too much speed, I'll see my algorithm again tomorrow.

Thank you Gernot you helped me without even answering me 

  Indeed, it's a very big problem for the player
Your problem interests me because I'm also developing a 3D project and have a similar problem, but not exactly the same as you.
But it's an FPS and not a spaceship simulation, that's probably the reason for the difference.

Glad you're found a solution and good luck on your project, Hemlos 

Do you have an example of your problem, Hemlos ?
Not your main code, just an example that sums up the problem you have in your pricinpale program.
Your problem intrigues me

When I reread Hemlos' comments, I thought it was a similar problem, but in fact it was not quite like mine (for me, it was with MOUSESTATE and only when there had a loss of FPS for a long time).
Moreover, I think my problem is not a GLB bug.

For the problem of Hemlos, you have probably the best solution MrPlow

Maybe, but seeing a SLEEP in a main loop bothers me a lot 

I already noticed this bug but I think that using a SLEEP in a main loop is not good.
Try not to multiply the speed of the mouse_velocity by a delta time but with a mouse_speed variable that the player of your game will be able to modify in the options.

Code (glbasic) Select Expand


delta_time = GETTIMER()
// mouse_x_velocity = mouse_x_velocity * delta_time
// mouse_y_velocity = mouse_y_velocity * delta_time
mouse_x_velocity = mouse_x_velocity * mouse_speed  // A variable between 0.0 --- 1.0 ----> 2.0 (or more) it's the player who will choose.
mouse_y_velocity = mouse_y_velocity * mouse_speed


And use this code in your main loop instead of MOUSEAXIS to get the velocity (and if everything works well, you'll be able to test with MOUSEAXIS).
   

Code (glbasic) Select Expand


MOUSESTATE mouse_x, mouse_y, mouse_b1, mouse_b2

// Your rendering ....

SETMOUSE screen_x_center, screen_y_center
mouse_x_velocity = mouse_x - screen_x_center
mouse_y_velocity = mouse_y - screen_y_center


I hope it will help you.

  Very good and nice example Erico.

Indeed, recompiling the source code could be a good idea, but my code will not be portable from one version to another 
Moreover, it's unfortunate that memory allocations are static and not dynamic (no difference between a cube or a complex object) and I guess it's the same for all other resources: sprites, sounds, ... 

For now I think I will dynamically allocate / deallocate objects in real time in my program (trying not to have too much slowdown).

Thanks for the confirmation Spacefractal.

Yes 

By cons, you are right in my test program it's not 4096 but 4224 the max     

I'm going to bed, this bug gives me a headache

Thank You Hemlos.

Hmm, I think you didn't understand the problem, but perhaps I'm poorly explained.
While you were answering me I wrote a modification in my first message, maybe it's clearer no?

If you exceed the number of 4096 objects in your program, your program crashes completely.

My engine is really optimized for software, but if it interests you (and maybe others), I would make an opengl version of my 3DS loader / renderer.
But not now because I have a problem with one of my projects (see the bugs section).
A problem that could also affect this future 3DS loader

Thank you for moving the topic.

Normally, GENX_OBJ() only returns -1 if there is not enough memory but that is not the case.
It seems that GLBASIC don't allow more than 4096 3d object.

------
EDIT
------
In fact, the GENX_OBJ()  function gives 4095 at the beginning and decreases with each call, it has nothing to do with the memory, this function is probably just in relation to a memory array of 4096.
It is very restrictive that the maximum number of objects is not related to the available memory (as the help says), but only with a precalculated memory array, because a 3D world can often contain more than 4096 objects