09-16-2025, 04:45 PM (This post was last modified: 09-16-2025, 04:50 PM by Marcus.)
(09-15-2025, 06:57 PM)johnno56 Wrote: Ok. It's not much of a change but I think it adds a little 'nostalgia' to the demo. Joystick (keyboard still works... lol) and 3 simple sounds.
Enjoy!
J
Nice!
Your joystick is analogue, right? 'joyx' and 'joyy' do return floating point values in the range [-1..1]. So how does the joystick work with this modification:
09-16-2025, 07:34 PM (This post was last modified: 09-16-2025, 07:43 PM by johnno56.
Edit Reason: added after thought.
)
(09-16-2025, 04:45 PM)Marcus wrote Wrote: Your joystick is analogue, right? 'joyx' and 'joyy' do return floating point values in the range [-1..1]. So how does the joystick work with this modification?
I remember the old 'atari style' sticks. The contacts were either on or off. -1, 0 and 1. My stick, depending on how far you move the handle, will produce varying values between -1 and 0; 0 and 1.
The stick needs to be fully moved to register 'movement'. Which means "-1" or "1". So, it is somewhat 'laborious', but it still works. As I stated earlier, the keyboard has a better response... It was just a 'lets see if it will works' kind of deal... lol
I hope that helps...
J
Oh, while I think of it...
The Triangles and Quads that you used for the 'ship', did you have to design (pencil and paper) yourself or did you use something like Blender to export the object? Just curious as to the process...
I'm good at visualizing 3d figures in my head and simply enter the coordinates, no need for modelling tools or pen and paper
The code snippet I pasted should deal with analogue joystick input, so that if you press your joystick 25% to the right, the ship should move slower in that direction. But maybe it didn't work as expected. Hm, gotta get an analogue controller myself to debug
"In your head"? Aw man... that says a lot about 'my' skills (or lack of them... lol) I was hoping for a method that could be replicated to create a model of choice... Me... I am a fan of pencil and paper... A physical representation... Your method requires imagination and creativity... *sigh*
In regards to the stick, I wouldn't waste too much effort, on that one... It was just an experiment... I thought that moving the stick slightly would move it 'slower' but it didn't. I had to reduce the angle to at least 30% of the original. When I first tried it, it moved way to fast, and it would only move when the stick movement was at its limit...
On the subject of sticks... Is there an N7 command for detecting the connection of a stick? Just curious...
09-17-2025, 04:44 PM (This post was last modified: 09-17-2025, 05:01 PM by Marcus.)
My son forgot to take his gamepad with him, xbox-thingy, when he moved out (again). I plugged it in and tried the code for analogue input that I posted yesterday and here it works fine This is the full source code, not just the changed part.
' Get ships direction as a vector.
S3D_ClearTransformation()
S3D_RotateY(rad(ship.rot.yaw))
S3D_RotateX(rad(ship.rot.pitch))
S3D_RotateZ(rad(ship.rot.roll))
S3D_TransformVector(ship.dir, fwdVec)
VectorNormalize(ship.dir)
' Uhm, slow down when close to x and y limits.
dxMul = 1; dyMul =1
if ship.dir[0] < 0 dxMul = min(ship.pos[0] - xMin, 4)*0.25
elseif ship.dir[0] > 0 dxMul = min(xMax - ship.pos[0], 4)*0.25
if ship.dir[1] < 0 dyMul = min(ship.pos[1] - yMin, 4)*0.25
elseif ship.dir[1] > 0 dyMul = min(yMax - ship.pos[1], 4)*0.25
' Obstacles.
i = vMinVisObstacle
while i < sizeof(vObstacles)
o = vObstacles[i]
dz = o.pos[2] - cam.pos[2]
if dz < -10 vMinVisObstacle = i + 1
if dz > vRenderDepth + 10
vMaxVisObstacle = i
break
endif
S3D_Push()
S3D_Translate(o.pos[0], o.pos[1], o.pos[2])
S3D_Mesh(o.mesh, 0)
S3D_Pop()
i = i + 1
wend
' Targets.
i = vMinVisTarget
while i < sizeof(vTargets)
t = vTargets[i]
dz = t.pos[2] - cam.pos[2]
if dz < -10 vMinVisTarget = i + 1
if dz > vRenderDepth + 10
vMaxVisTarget = i
break
endif
t.rot.yaw = (t.rot.yaw + t.dyaw)%360
DrawObject(t)
i = i + 1
wend
DrawObject(ship)
foreach b in bullets DrawObject(b)
S3D_RenderFog(48, 96, 128, false)
if hitParam > 0
set color 192, 0, 0, hitParam*255
cls
endif
' Obstacle
' --------
function Obstacle(mesh, x, y, z, w, h, d)
o = [
mesh: mesh,
pos: [x, y, z],
box: [x - w*0.5, y - h, z - d*0.5, x + w*0.5, y, z + d*0.5]]
return o
endfunc
' Target
' ------
function Target(x, y, z)
t = []
t.mesh = vTargetMesh
t.pos = [x, y, z]
t.box = [x - 2, y - 1.5, z - 2, x + 2, y + 1.5, z + 2]
t.rot = [yaw: rnd()*360, pitch: 0, roll: 0]
t.shd = [img: vTargetShadowImage, scale: 1, size: 4.4]
t.dyaw = rnd()*12 - 6
return t
endfunc
' BoxesOverlap
' ------------
function BoxesOverlap(a, b)
return not (a[2] > b[5] or b[2] > a[5] or a[0] > b[3] or b[0] > a[3] or a[1] > b[4] or b[1] > a[4])
endfunc
Here I output that 'joyx' and 'joyy' values and as you can see the ship moves slower when I just press the controller slightly.
There's currently no way to detect whether a controller is plugged in or not. When the window is created I ask to receive events for joystick id 1, then I forward any such events to n7. If there's no controller plugged in when the window is created, the program won't be able to read joystick input. So it's better to write code that works for both joysticks and keyboard .
10-18-2025, 07:06 AM (This post was last modified: 10-18-2025, 07:16 AM by Marcus.)
Sorry for not posting in a while, been a couple of busy weeks.
This version of the program would look like crap without the latest, unreleased, version of n7. I've just changed the rasterizer for un-textured polygons so that it writes perspective correct z values to the depth buffer. Without that, the ground would look really, really weird - gradients going all over the place.
While testing this program I managed to make the n7 runtime enter a state where it ran SUPER slowly (fps dropped to 10). The runtime needs some memory just for executing, and if there's too little memory left (close to trigger "garbage collecting" but not quite there yet), things get slow. So I shall dive into the darkness of my memory managment code and fix this issue before releasing a new version of n7. In theory the solution is easy: don't wait with garbage collecting until there's NO memory left, do it when there's like 25% left, and increase the heap size if not much memory could be released. But in practice, it will most likely be a nightmare to fix
This might sound like a stupid question... Garbage? I am not all that familiar with this 3D type of stuff... Garbage and memory... In layman's terms, would you be so kind as to explain the relationship? What part of the process is using, or requiring, the most memory?
If memory (no pun intended) serves correctly, Star Fox, was from the early 90's and the average home PC ran with anything up to 8mb of ram running Win3.1 and DOS5. The SNES, at the time, has 128kb of work ram and 64kb of video ram.
I am totally confused... 30 years later, our PC's, now have built-in memory exceeding 8gb of ram with CPU's that run WAY faster... Either those programmers of yester-year were Wizards or there is something else that does not make sense... In 1993 the game ran flawlessly running with either 128kb or 4-8mb of ram... and 'we' have memory issues today? I wander what has changed? lol Not a judgement or criticism, just curious... I miss the old days... Simpler times...
10-18-2025, 10:26 AM (This post was last modified: 10-18-2025, 10:56 AM by Marcus.)
(10-18-2025, 09:35 AM)johnno56 Wrote: This might sound like a stupid question... Garbage? I am not all that familiar with this 3D type of stuff... Garbage and memory... In layman's terms, would you be so kind as to explain the relationship? What part of the process is using, or requiring, the most memory?
If memory (no pun intended) serves correctly, Star Fox, was from the early 90's and the average home PC ran with anything up to 8mb of ram running Win3.1 and DOS5. The SNES, at the time, has 128kb of work ram and 64kb of video ram.
I am totally confused... 30 years later, our PC's, now have built-in memory exceeding 8gb of ram with CPU's that run WAY faster... Either those programmers of yester-year were Wizards or there is something else that does not make sense... In 1993 the game ran flawlessly running with either 128kb or 4-8mb of ram... and 'we' have memory issues today? I wander what has changed? lol Not a judgement or criticism, just curious... I miss the old days... Simpler times...
There's actually nothing that requires much memory. It's just that n7 is a language that uses a "garbage collector" to deal with "lost memory". Whenever the running program needs memory for something, like a new bullet in this game, it asks the "memory manager" for a slice of memory. The memory manager is lazy and doesn't keep track of what old slices of memory are still in actual use by the program; it just gives the running program a new slice from the big memory cake. If the memory manager can't find a slice of the requested size, it performs garbage collecting. By examining all the variables in the running program, it determines which memory slices are still actually used. All un-used memory slices are made available again for the program. If the memory manager still can't find a slice of memory, it simply creates another cake.
The slowdown occurred when there was just a tiny slice of memory left but before the garbage collector was invoked. So ... I need to do change the memory manager so that it doesn't wait with garbage collecting until it's actually out of cake.
The default memory cake size in an n7 program is 16MB but can be made smaller or larger via the "mem" flag. If you look at the source code of NED, you can see that it requests a cake size of 64MB (#mem64000000). That way the garbage collector is invoked less often.
