Question about _MAPTRIANGLE, hardware images, and image handles... :'(

[jakeh0916]

Hey everyone, I'm trying to figure out _maptriangle and hardware images here. My intention is to use _maptriangle to map some triangles onto a mode 33 image. Then use _putimage to place that image on the screen. The reason I want to do this instead of just using _maptriangle to directly put triangles on the screen is that I want to preserve the screen resolution (which should be 500x500 here) in fullscreen mode. _FULLSCREEN _SQUAREPIXELS has no effect when using _MAPTRIANGLE in 3d mode, as far as I can tell... and I know of no other way to properly scale a small screen to fullscreen without smoothing it and stretching it.

Anyway, the problem with the current method is that it eats up memory like crazy (starts at around 60MB, steadily increases until crash), and I think it's pretty obvious what the issue is: it's copying that image (background&) to a new mode 33 image every single frame. I'm not sure how to deal with this though, since I don't believe you can _FREEIMAGE a mode 33 image (since its handle is negative) and I don't know how to do this projecting in any other way. (I could be wrong about _FREEIMAGE, though, as I did try it once and it didn't give me an error trying to free the mode 33 image. But, even with "freeing" the image every frame before copying a new one, the memory still rose until the program crashed.)

If you have any ideas or see what I'm messing up here... let me know!

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(500, 500, 32)
2.  
3. ' Load a mode 33 texture for _maptriangle to use
4. DIM texture&
5. texture& = _LOADIMAGE("tex", 32)
6. DIM SHARED texture33&
7. texture33& = _COPYIMAGE(texture&, 33)
8. _FREEIMAGE(texture&)
9.  
10. ' Load an image to use as the background; say, a sunny sky, etc.
11. ' This should be the same size as the screen
12. DIM SHARED background&
13. background& = _LOADIMAGE("bg", 32)
14. DIM SHARED background33&
15.  
16. DO
17.    _LIMIT 60
18.      
19.    _DEST 0: CLS
20.    ' Make a mode 33 copy of background to use in the following method...
21.    background33& = _COPYIMAGE(background&, 33)
22.    CALL RenderTrianglesToBackground
23.    
24.    ' Paste background33 image with rendered triangles to screen
25.    _PUTIMAGE(0,0), background33&
26.    _DISPLAY
27. LOOP
28.  
29. SUB RenderTrianglesToBackground
30.    FOR i = 0 TO 99
31.       ' Map a triangle to some 3d space from some texture space... -> onto background33&
32.       _MAPTRIANGLE _ANTICLOCKWISE (t0u, t0v)-(t1u, t1v)-(t2u, t2v), texture33& TO(v0x, v0y, v0z)-(v1x, v1y, v1z)-(v2x, v2y, v2z), background33&
33.    NEXT
34. END SUB
35.  

[SMcNeill]

You need a _DISPLAY before the end of your loop.

Hardware images won’t render, or leave memory, until _DISPLAY is called.  Toss one in there after the Putimage and let me know how it performs. 

[jakeh0916]

Oops, that's just a typo. I wrote that sample code for demonstration... I've got a display in there in my actual program, and the displaying works great. The PUTIMAGE scales properly with the screen and keeps its resolution, it's just that the copying of a bunch of software -> hardware images seems to leak memory somewhere.

[jakeh0916]

Here, I've found this from the wiki as well.

Code: QB64: [Select]

1. CONST MenuHeight = 200
2.  
3.  
4. SCREEN _NEWIMAGE(640, 480, 32)
5. 'SLEEP 1
6. LOCATE 20
7. DO
8.     _LIMIT 60
9.     DisplayMenu
10.     k = _KEYHIT
11.     IF k <> 0 THEN PRINT k,
12. LOOP UNTIL k = 32 OR k = 27
13.  
14.  
15. SUB DisplayMenu
16.     STATIC init, MS_HW AS LONG
17.     IF NOT init THEN
18.         init = -1
19.         MS = _NEWIMAGE(640, MenuHeight, 32) 'MenuScreen image
20.         D = _DEST: _DEST MS
21.         CLS , &HFFAAAAAA 'background color gray
22.         _PRINTSTRING (20, 2), "Menu Test" 'image text
23.         MS_HW = _COPYIMAGE(MS, 33) 'create the MenuScreen_HardWare image
24.         _FREEIMAGE MS
25.         _DEST D
26.     END IF
27.     _PUTIMAGE (0, 0)-(640, MenuHeight), MS_HW
28.     _DISPLAY
29. END SUB
30.  

When I run this at a high frame rate, it seems to also leak some memory. As the program sits, the memory used increases steadily...
Not sure what's causing this. Anyone know of a way to avoid this but get a hardware image wiped, written & drawn to the screen each frame?

[SMcNeill]

What OS?  Version of QB64?

In Win 10, with QB64x64, I run the test code and memory usage stays steady at 57.4MB.  I'm not seeing a leak from this.  Is it OS specific?

[jakeh0916]

I'm running QB64-1.2 on Windows 10, because I had a problem with _MOUSEMOVEMENTX/Y in 1.4.

Could definitely be some legacy bug. Ran the program again (the one from the wiki) and had memory increase from 40.1 MB to 52.2 MB over about ten minutes, and it was a pretty gradual increase throughout. I'd say this is kind of insignificant, but it looks like the same issue is getting magnified on my other program and causing a lot more memory to leak--or something, idk. I'm going to try it in QB 1.4 and see how that handles...

[jakeh0916]

Incredibly, it does seem to be that me running an old version of QB64 was the problem. Who would've guessed.
Now if only I can get _MOUSEMOVEMENT working on 1.4!

[jakeh0916]

Oh.. encountered the issue again, actually. I'm going to make a new post with a better example/title for this because I think I've made this one a little convoluted!

[FellippeHeitor]

_MOUSEMOVEMENT has been fixed in upcoming v1.5. You can already start using it though: https://www.qb64.org/portal/development-build/