Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jakeh0916

Pages: [1]
1
QB64 Discussion / Question about DIMing user-defined types
« on: March 03, 2021, 05:45:36 pm »
Hi everybody, I had a quick question about DIM and how it works with user-defined types.

Say I create a type for a 3d point,
Code: QB64: [Select]
  1. Type vec3
  2.    x as double
  3.    y as double
  4.    z as double
  6.  

When I DIM something of this type, can I safely assume that it will always DIM the type with defaulted values (x = 0, y = 0, z = 0), or is there a chance that the program will reuse some bits of memory, and end up with my x, y or z variables equaling something other than 0? The superstitious part of me wants to do something like this to ensure that my variables always get set up properly:

Code: QB64: [Select]
  1. ' Set up some "default" variable at the beginning of the script...
  2. Dim Shared vec3_default as vec3
  3. vec3_default.x = 0
  4. vec3_default.y = 0
  5. vec3_default.z = 0
  6.  
  7. ' And use that default variable to initialize any DIMed variable
  8. Dim someRandomPoint as vec3
  9. someRandomPoint = vec3_default
  10.  

So my question is, in general: when you DIM a user defined type, does the program make sure to reset all of the bits and whatnot in memory, or does it just dimension the variable without looking at whether there was already some stuff there in memory? My thinking is that it will actually reset the memory when it DIMs any variable, but I wasn't quite sure.

2
QB64 Discussion / Re: MIDI-piano v2
« on: February 19, 2021, 12:55:44 pm »
Wow, this is great. Definitely gonna download and give this thing a whirl B-)

3
QB64 Discussion / Super Mario 64 level rendered in QB64 (no opengl)
« on: February 18, 2021, 05:52:37 pm »
Brought to you by _MAPTRIANGLE (3d with hardware images, but absolutely no other OpenGL components) and lot of matrices.

The model is fully 3d-rendered and textured with a camera capable of flying around and clipping all the tris, running at around 250fps, 1080x720. One day, maybe, I'll use this engine to make a game with QB64, but that requires a lot of time which I've been finding scarce lately.. Let me know what you all think!

(screenshot attached)

4
QB64 Discussion / Re: Question about _MAPTRIANGLE, hardware images, and image handles... :'(
« on: February 12, 2021, 04:58:19 am »
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!

5
QB64 Discussion / Re: Question about _MAPTRIANGLE, hardware images, and image handles... :'(
« on: February 12, 2021, 04:36:48 am »
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!

6
QB64 Discussion / Re: Question about _MAPTRIANGLE, hardware images, and image handles... :'(
« on: February 12, 2021, 03:08:28 am »
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...

7
QB64 Discussion / Re: Question about _MAPTRIANGLE, hardware images, and image handles... :'(
« on: February 12, 2021, 01:15:28 am »
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
  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
  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?

8
QB64 Discussion / Re: Question about _MAPTRIANGLE, hardware images, and image handles... :'(
« on: February 12, 2021, 01:04:36 am »
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.

9
QB64 Discussion / Question about _MAPTRIANGLE, hardware images, and image handles... :'(
« on: February 12, 2021, 12:05:48 am »
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.  
  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&
  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
  35.  

Pages: [1]