BBC BASIC for Windows
IDE and Compiler >> Tools and Utilities >> 3D Odometer counter IMPROVED
http://bb4w.conforums.com/index.cgi?board=addins&action=display&num=1507637567
3D Odometer counter IMPROVED
Post by michael on Oct 10th, 2017, 12:12pm

The 3d odometer is greatly improved and is nicely shrunk down to fit in the lowest corner.

INSTRUCTIONS: Use your RIGHT mouse button to modify the odometer.. ( the arrow buttons control the odometer )

You can modify the limit to 99 ( inside the program that is...)


https://1drv.ms/f/s!AmYwmTjbmULXlx9FCGi2KuiF00h8
Re: 3D Odometer For 3D counter (needs to be smalle
Post by DDRM on Oct 10th, 2017, 4:53pm

Hi Michael,

The numbers seem to be backwards/upside down?

The texture picture needs to have a size such that it is an exact power of 2 in each direction. That's why you get those black borders.

I loaded it into Paintshop Pro (other photoediting programs available!), flipped it X and Y, and resized it to 32 wide and 128 high, and it fits fine, though it's a bit pixellated! I made a replacement 64 x 256, which looks nicer.

What are you planning to use it for?

D
Re: 3D Odometer For 3D counter (needs to be smalle
Post by michael on Oct 10th, 2017, 7:50pm

Quote:
What are you planning to use it for?


Well I want to make a few public objects that people can use to interface within the renderer. For object editors, and maybe some types of games..

Being able to monitor the status of things in a renderer or game would be handy.

I would say, eventually, I want to create tools that anyone can easily use.

I may also add all your objects in the app so that a person can easily select the type of image and the size and all sorts of mods all on an interactive renderer.

I will create a program generator too to offer stand along modules or 3D code constructs.
Re: 3D Odometer counter IMPROVED
Post by DDRM on Oct 16th, 2017, 4:21pm

Hi Michael,

Here's a version with a few suggestions for changes:

I've stripped out some unneeded complexity: you had cou%, rn%, numstr$, num1str$, and num2str$ all involved in tracking the number on display. I've removed all except rn%.

Rather than a list of instructions to set the rotation for each digit of each rotor, I've simply rotated it according to the digit it displays.

I wasn't sure what pass% was doing, so I've simply stripped it out.

I moved everything that only needs doing once (such as loading the objects and setting their positions) out of the loop. This also avoids the need to keep throwing them away again (PROCclrit)!

You had two copies of PROCcleanup, but neither cleaned up all the objects you had loaded (neither did PROCclrit), because you had increased to 4 objects, but were still only releasing the first 2. I've amended it to release however many are defined by nshapes. I've also provided the values to clear as parameters, since they aren't given names consistent with them being globals, and it also reminds you what you are actually clearing.

A bit more subtly, I've swapped the right hand rotor to b%(0), and the left to b%(1). This is really thinking ahead: this way it's relatively easy to add another rotor: you simply move the existing ones right a bit, and add a new rotor in b%(2). You can also simply modify p(2) from the p(1) example, by changing it to DIV 100 - and you could go on adding rotors as long as you wanted.

I've only loaded the rotor and the texture once, then copied the results into the slots for the second one. Arguably that's a bit cheeky, but it works, and it saves space (you only hold one copy in memory). It's possible that won't work in SDL - if it doesn't, I'd be interested to know.

I've swapped the way your arrows change the number, so the upper one makes it increase, which seems more logical to me. I also "debounced" the mouse, so you can make changes of 1 accurately, but it does mean you can't hold the mouse down to make it change continuously. I've allowed both mouse buttons to work, but you could easily change that.

I've added a test to allow you to exit by pressing Q or q.

I note that you read the mouse basically by seeing whether it is in the rectangle overlying the arrow objects. That works for now, but seems a slightly risky approach for D3D objects, which, more or less by definition, are likely to be viewed from different directions (otherwise why not just draw them flat?).

I suspect that's partly a compromise driven by the fact that you can't mix D3D and BB4W graphics in the same window. In BB4W, but not BBC-SDL, you could get round that by defining a window (using Winlib5, I think from memory),and sticking the D3D graphics in that, but I know you are keen to retain cross-platform flexibility.

Hope that's useful/interesting.

D

Code:
      MODE 8
      rn%=0
      peak=0
      IF INKEY$(-256)="W" INSTALL @lib$+"D3DLIBA" ELSE INSTALL @lib$+"OGLLIB"
      LET nshapes=3
      DIM l%(0), b%(nshapes), n%(nshapes), f%(nshapes), s%(nshapes), m%(nshapes), t%(nshapes), y(nshapes), p(nshapes), r(nshapes), X(nshapes), Y(nshapes), Z(nshapes), e(2), a(2)

      IF INKEY$(-256)="W" d% = FN_initd3d(@hwnd%, 1, 0) ELSE d% = FN_initgl(@hwnd%, 1, 0)
      IF d% = 0 ERROR 100, "Can't initialise Direct3D"

      b%(0) = FN_load3d(d%, @dir$+"cylinder.FVF", n%(0), f%(0), s%(0))
      IF b%(0) = 0 ERROR 100, "Can't load TRIANGLE.FVF"
      t%(0) = FN_loadtexture(d%, @dir$+"0123456789 backup.BMP")
      IF t%(0) = 0 ERROR 100, "Can't load face.JPG"
      b%(1) = b%(0):n%(1)=n%(0):f%(1)=f%(0):s%(1)=s%(0)
      t%(1) = t%(0)
      b%(2) = FN_load3d(d%, @dir$+"triangle microup.FVF", n%(2), f%(2), s%(2))
      IF b%(2) = 0 ERROR 100, "Can't load TRIANGLE.FVF"
      b%(3) = FN_load3d(d%, @dir$+"triangle microdown.FVF", n%(3), f%(3), s%(3))
      IF b%(3) = 0 ERROR 100, "Can't load TRIANGLE.FVF"

      ON CLOSE PROCcleanup(nshapes,d%,b%(),t%()):QUIT
      ON ERROR PROCcleanup(nshapes,d%,b%(),t%()):PRINT REPORT$:END
      e() = 0, 0, -6
      a() = 0, 0, 0
      l%()=1
      y(0)-=0.44
      y(1)-=0.42

      REM X (right left)
      X(0) = -0.467
      X(1) = -0.52
      REM Y() up and down
      Y(0) = -0.32
      Y(1) = -0.32
      REM Z() depth
      Z(0) = -5
      Z(1) = -5
      X(2)=-0
      Y(2)=-0.27
      Z(2)=-5.95
      X(3)=-0.375
      Z(3)=-5.7
      Y(3)=0.05

      REPEAT
        MOUSE mx,my,mb
        IF mx>54 AND mx<76 AND my>5 AND my<100 AND mb>0 THEN rn%-=1
        IF mx>54 AND mx<76 AND   my<236 AND my>192 AND mb>0 THEN rn%+=1
        REPEAT MOUSE mx,my,mb UNTIL mb=0
        IF rn%>99 THEN rn%=99
        IF rn%<0 THEN rn%=0
        p(0)=-(rn% MOD 10)*PI/5
        p(1)=-((rn% DIV 10) MOD 10)*PI/5
      ENDIF
      PROC_render(d%, &FF7F7F7F, 0, l%(), 4, m%(), t%(), b%(), n%(), f%(), s%(), y(), p(), r(), X(), Y(), Z(), e(), a(), PI/4, 5/4, 1, 1000, 0) :REM experimental
      WAIT 5
      q$=INKEY$(0)
      UNTIL q$="q" OR q$="Q"
      finished%=TRUE
      PROCcleanup(nshapes,d%,b%(),t%())
      END
      :
      DEF PROCcleanup(numshapes,d%,b%(),t%())
      LOCAL x%
      FOR x%=0 TO numshapes
      t%(x%) += 0:IF t%(x%) PROC_release(t%(x%))
      b%(x%) += 0:IF b%(x%) PROC_release(b%(x%))
      NEXT x%
      d% += 0   :IF d%    PROC_release(d%)
      ENDPROC
Re: 3D Odometer counter IMPROVED
Post by michael on Oct 16th, 2017, 5:40pm

Quote:
I wasn't sure what pass% was doing, so I've simply stripped it out.

I moved everything that only needs doing once (such as loading the objects and setting their positions) out of the loop. This also avoids the need to keep throwing them away again (PROCclrit)!


Thanks for the improvements.

pass% was meant to eliminate the unnecessary mouse position checks and modification of the odometer. So if the right mouse button was pressed it would check the zone the mouse was in. ( I could have probably done a more effective coding for that)

(PROCclrit) will become necessary later when I finally merge all the tools in the 3D editor. The edited image will be manipulated without moving the eye.

So I wont be worried about the 3D controls moving.

I feel it is necessary to attempt to find ways to create 3D interface style tools as it will open doors later. And it will also keep me focused on 3D so that eventually I become skilled in this.

I have an idea of creating 3D constructs that can be edited like mini screens. That would involve editing the texture file and updating it....

OR the ultimate method would be to somehow modify the texture image directly... ( you know how?)

As I am sure for many, I am struggling to stay focused on being productive. I am progressing at the speed of a glacier .

I eventually want to make a 3D game, and of course finish my 3D editor.

I do appreciate your efforts.
Re: 3D Odometer counter IMPROVED
Post by DDRM on Oct 17th, 2017, 08:11am

Hi Michael,

I guess you could load the texture into a DIBsection - then you could edit it live. That would mean incorporating a reasonably good image editor into your 3D editor, which might be more complexity than you really need. I can see it might be useful to display the texture image though, and perhaps select areas of it to use to clothe a primitive by dragging a rectangle?

I take your point about wanting to reload the image as it gets updated in the longer term, but I'm still not convinced doing it *every time you go round the refresh cycle* is a good plan - its pretty slow (since the whole point is you can't use a cached version if it is being updated), and if there is any failure to release the components you are loading you will generate a huge memory leak.

How about checking the file's "last modified" time, and only updating if it has changed? If you integrated the editor and the renderer, you could simply have a variable recording whether the file had changed, which would avoid needing file accesses.

Best wishes,

D