BBC BASIC
Programming >> Graphics and Games >> 3D Odometer For 3D counter (needs to be smaller)
http://bbcbasic.conforums.com/index.cgi?board=graphics&action=display&num=1507637753
3D Odometer For 3D counter (needs to be smaller)
Post by michael on Oct 10th, 2017, 12:15pm

INSTRUCTIONS:

Use your RIGHT mouse button on the left and right sides of the screen to pivot the odometer left and right and
to roll it up and down use the RIGHT mouse button on the top and bottom of the screen.

https://1drv.ms/f/s!AmYwmTjbmULXlxMq9S2CXYadtbMY

I modified the 3D cylinder DDRM provided for me so it doesn't have the caps.

To give an idea of how small the cylinder must be.. it must be small enough to be placed at around -4 or -3 on the Z depth, as it would be used to display numbers in the 3D renderer. (The numbers took a bit of tweaking to line up on the cylinder)

Thankyou DDRM and thank you Richard for your help
Re: 3D Odometer For 3D counter (needs to be smalle
Post by DDRM on Oct 10th, 2017, 4:49pm

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.


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

you should be able to flip it with the right mouse button and then the numbers would be right.

Top,bottom will turn it and right and left side of screen will flip it to the right orientation.

I would be happy to see your version. It does need to be a tiny cylinder so it can be near the eye.. at around -3 to -4 (somewhere in there)
the active number would stick out of the displayed interface area which would be partly submerged in the cylinder ..
Re: 3D Odometer For 3D counter (needs to be smalle
Post by Richard Russell on Oct 10th, 2017, 8:49pm

on Oct 10th, 2017, 4:49pm, DDRM wrote:
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.

That's true only in BB4W, and then only with the current libraries (D3DLIB etc.). If you compare 'pyramid.bbc' running on BB4W and BBCSDL, the 'clock background' graphic has black borders on the former but fills the pyramid base on the latter.

As far as I am aware all modern GPUs can cope with NPOT texture dimensions and I should probably remove the library code that is currently enforcing it, in order to improve compatibility with BBCSDL. I've just tried making that change to D3D9LIB and it seems to work fine on this PC.

Today I had my latest creation running on nine machines simultaneously: the Amazon Fire TV Stick, three Android tablets, a Ubuntu Linux PC, two Macs, a Raspberry Pi and a Windows PC running BBCSDL - not a single one was running BB4W, although the program works without modification on that too.

Richard.
Re: 3D Odometer For 3D counter (needs to be smalle
Post by DDRM on Oct 11th, 2017, 08:11am

Hi Richard,

Ooh, OK, that would be nice! It would make designing textures noticeably easier.

Best wishes,

D
Re: 3D Odometer For 3D counter (needs to be smalle
Post by Richard Russell on Oct 11th, 2017, 08:51am

on Oct 11th, 2017, 08:11am, DDRM wrote:
Ooh, OK, that would be nice! It would make designing textures noticeably easier.

You don't need me to make the change! Just whip out the 'force to power-of-two' code in D3D9LIB and D3D9LIBA (save the edited libraries as a different name if you prefer). That's all I did as an experiment - nothing 'complicated' - and it seemed to work.

Richard.
Re: 3D Odometer For 3D counter (needs to be smalle
Post by DDRM on Oct 11th, 2017, 12:22pm

Hi Richard,

OK, so I looked at FN_loadtexture, and changed:

After SYS"GetObject", I set X% to W% and Y% to H%

Better, assuming I've got things right, I can eliminate X% and Y%,and just use W% and H% in the call to CreateTexture.

Just before SYS"GetDIBits", I simplified the P% definition to P%=R%!4

That seems to work on a quick test: am I missing anything?

Best wishes,

D
Re: 3D Odometer For 3D counter (needs to be smalle
Post by Richard Russell on Oct 11th, 2017, 2:44pm

on Oct 11th, 2017, 12:22pm, DDRM wrote:
OK, so I looked at FN_loadtexture, and changed:

You obviously thought about the code (and understood it to some degree), a luxury I no longer have. The change I made was therefore more naïve; I changed:

Code:
      X%=1:REPEAT X%*=2:UNTIL X%>=W%      Y%=1:REPEAT Y%*=2:UNTIL Y%>=H%

to Code:
      X%=W%      Y%=H%

Do you consider that mod to be somehow unacceptable? It's what I am planning to do in the distributed versions, unless you advise otherwise.

I certainly didn't consider changing anything else, such as the line starting P%=R%!4, because I don't know what it does. I've not noticed anything untoward as a result.

Richard.
Re: 3D Odometer For 3D counter (needs to be smalle
Post by DDRM on Oct 12th, 2017, 08:32am

Hi Richard,

> a luxury I no longer have
Oh, Richard, I'm so sorry. It must be incredibly frustrating! :'(

Arguably the change to the line P%=R%!4... is redundant, since (Y%-H%) and (X%-W%) will now both be 0, so the other terms will drop to 0. That made me feel it was OK to take them out. I also couldn't work out exactly what it did (I couldn't work out from the DirectX9 documentation, which is what I have, exactly what was ending up in R%), but I guess it centred the actual image on the space reserved, thus giving an even black border all round when padded to a power of 2.

I think your change would be perfectly acceptable, though it leaves some rather opaque but harmless code!

Here's my version, if it's useful. I've taken out X% and Y% completely. Tested, but not extensively.

Best wishes,

D
Code:
      DEF FN_loadtexture(D%,f$)      LOCAL B%,F%,G%,H%,I%,J%,K%,L%,M%,O%,P%,R%,S%,T%,W%      DIM S% LOCAL LEN(f$)*2+3,M% LOCAL 86,F% LOCAL 42,R% LOCAL 7      M%=(M%+3)AND-4      F%=(F%+3)AND-4      SYS"LoadLibrary","OLEAUT32.DLL" TO O%      SYS"GetProcAddress",O%,"OleLoadPicturePath" TO O%      IF O%=0 THEN=0      I%=&7BF80980      J%=&101ABF32      K%=&AA00BB8B      L%=&AB0C3000      SYS"MultiByteToWideChar",0,0,f$,-1,S%,256      SYSO%,S%,0,0,0,^I%,^G%      IF G%=0 THEN=0      SYS!(!G%+12),G%,^B%:REM get_Handle      SYS"GetObject",B%,84,M%      W%=M%!4      H%=M%!8      SYS!(!D%+80),D%,W%,H%,0,0,21,1,^T%:REM CreateTexture      IF T%=0 THEN=0      SYS!(!T%+64),T%,0,R%,0,0:REM LockRect      F%!0=40      F%!4=W%      F%!8=-H%      F%!12=&200001      P%=R%!4      FOR I%=0 TO H%-1        SYS"GetDIBits",@memhdc%,B%,I%,1,P%,F%,0        P%+=!R%      NEXT      SYS!(!T%+68),T%,0:REM UnlockRect      SYS!(!G%+8),G%:REM Release      =T%

Re: 3D Odometer For 3D counter (needs to be smalle
Post by Richard Russell on Oct 12th, 2017, 11:27am

on Oct 12th, 2017, 08:32am, DDRM wrote:
Oh, Richard, I'm so sorry. It must be incredibly frustrating! cry

It is, but I am grateful that I can still write and understand 'ordinary' BASIC code reasonably well, and it keeps my working brain cells exercised!

My inexpert judgement is that it's more a problem of memory than of cognition. If I spend long enough reminding myself of the APIs etc. I can still understand them, but I have to start from scratch every time.

Quote:
Arguably the change to the line P%=R%!4... is redundant, since (Y%-H%) and (X%-W%) will now both be 0, so the other terms will drop to 0.

Ah, I see, yes; even without knowing what the code does in detail you can tell that the later terms now evaluate to zero. However I've not bothered to make your changes here since any time saving will be insignificant.

I've checked and, as expected, the modified libraries run OK in Windows 7 and later but not in Windows XP (of course it may well also depend on the graphics 'card', but I've not been able to test that). By changing only D3D9LIB(A), and not D3DLIB(A), hopefully it won't affect compatibility too much.

Richard.