• Print

Author Topic: "Out Of Memory"  (Read 709 times)

Pete

  • Moderator
  • Hero Member
  • *****
  • Posts: 6240
  • Cuz I sez so varmint!
Re: "Out Of Memory"
« Reply #15 on: April 21, 2012, 02:55:42 PM »
I'd make the drawing routine a sub, rather than accessing it with GOSUB. When the sub is exited, the memory should be freed up. Might work, might not, but it sounds like the trial and error stage is the only game in town if you don't want to send the source to the developer.

Pete
It's only rocket science; it's not Linux!

pitt

  • Full Member
  • ***
  • Posts: 243
    • Email
Re: "Out Of Memory"
« Reply #16 on: April 21, 2012, 03:15:23 PM »
I still haven't gotten an answer to my memory limit question; why is QB64 limited to 148MB of RAM when other 32-bit applications like Photoshop, Battlefield 3 and so on use 50MB-2GB of RAM? I'm sorry, but I'm used to HTML. PHP, JAVA, etc .... they depend on system resources and don't shout of "I AM OUT OF RAM FOR SOME UNKNOWN REASON" all of the time.
« Last Edit: April 21, 2012, 03:22:29 PM by pitt »

pitt

  • Full Member
  • ***
  • Posts: 243
    • Email
Re: "Out Of Memory"
« Reply #17 on: April 21, 2012, 03:20:50 PM »
Quote from: Pete on April 21, 2012, 02:55:42 PM
I'd make the drawing routine a sub, rather than accessing it with GOSUB. When the sub is exited, the memory should be freed up. Might work, might not, but it sounds like the trial and error stage is the only game in town if you don't want to send the source to the developer.

Pete

There are many sub's and gosub's that write to the workscreen(1). Some depend on 20-50 variables to be passed between each other. I found it more practical to to use gosub instead of sub as the gosub in my example uses ZERO, notta, none variables that wouldn't be passed to the SUB (if I were to make it one). So I do not see how it would make any difference at all as all variables are used and nothing is there to be "freed up". I do use sub's a lot for routines that share little variables and have lots of their own. I will move it to a sub and report back, but I doubt anything will change.

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: "Out Of Memory"
« Reply #18 on: April 21, 2012, 03:48:00 PM »
Does the workscreens really need to be in such a large state? 
Quote
workscreen(1) = _NEWIMAGE(2048, 1536, 32)

A screen that size has over 3 Million pixels to track and keep up with, and at 32bit color, that's a whole lot of memory for each page, and you said you had 4 different workscreens...

I'd say, if you swapped down to a 1024 x 720 x 32 screen a lot of the trouble might clear up.  Use a _FULLSCREEN _STRETCH if your monitor display is a whole lot larger, and you still want to see the rests across the whole screen.

Quote
Some depend on 20-50 variables to be passed between each other.

With that many variables being passed back and forth, you might want to look at the newest _MEM commands to place it all up in a free block of memory, and call it from there.

EDIT:  In response to:
Quote
I still haven't gotten an answer to my memory limit question; why is QB64 limited to 148MB of RAM when other 32-bit applications like Photoshop, Battlefield 3 and so on use 50MB-2GB of RAM? I'm sorry, but I'm used to HTML. PHP, JAVA, etc .... they depend on system resources and don't shout of "I AM OUT OF RAM FOR SOME UNKNOWN REASON" all of the time.

QB64 isn't limited to 148 MB of ram.  My Shuffle game (you can download it in the sample area, if you want), doesn't FREEIMAGE at all.   I wasn't used to the new QB64 commands when I wrote it, so it NEVER frees up memory.   I just started it up, ran it and loaded new picture after new picture, and each time the memory it used went up a nice chunk.  After many times, it passed the 1GB mark and was still running happily.  (But I do need to fix that sometime.)

IF the program is crashing after 148M of ram, it's got to be one of your variables or arrays going out of bounds I'd think.  QB64 easily runs with a much larger strain than that on it.  Just play Shuffle (or just load pictures from the options a few dozen times), and you can see that for yourself.  :)
« Last Edit: April 21, 2012, 04:14:15 PM by SMcNeill »
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

pitt

  • Full Member
  • ***
  • Posts: 243
    • Email
Re: "Out Of Memory"
« Reply #19 on: April 22, 2012, 02:03:53 AM »
Quote from: SMcNeill on April 21, 2012, 03:48:00 PM
if you swapped down to a 1024 x 720 x 32 screen a lot of the trouble might clear up. 

I'm not going to shrink the size of my game buffers therefor shrinking the size of each map to a mere 1024x720 to work around memory issues that should not exist. This is not a possibility also due to the fact the scripts and locational data for each map would have to be re-done. I would rather piss on it and delete it then go through the entire map creation process again. A single map takes at least 16 hours and I have a cap of 9999 maps (not that I've done that many, but I've done enough). There is no way I'm doing that all over again and the quality of a game with barely any map area would be shit

I replied the original question of the "ERROR CODE", but still have not gotten a response to what that means. Is there a database of errors and their respective numbers?

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: "Out Of Memory"
« Reply #20 on: April 22, 2012, 02:43:38 AM »
Hi pitt,

Quote
I replied the original question of the "ERROR CODE", but still have not gotten a response to what that means. Is there a database of errors and their respective numbers?
Critical Error #1 is a generic out of memory error.

There's a lot of well intended but poor advice being floated around here. I suggest you use your discretion and be selective about what advice you choose to follow.

The whole 148MB (or whatever it may be) seems very unusual to me, especially with your memory specifications.

I'm willing to investigate your program in confidence (I won't share any of your code or content with others) and give you some better informed advice. I recommend you Email it, any supporting files and instructions on how to replicate the error to galleondragon@gmail.com. Without sharing your code with someone you will continue to get well meaning but probably not so useful advice.

I don't want your effort to be wasted either.

Regards,
Galleon

PS. I'm a bit like snail mail on my Email so if you choose to do this don't forget to let me know you sent it.
Something old... Something new... Something borrowed... Something blue...

pitt

  • Full Member
  • ***
  • Posts: 243
    • Email
Re: "Out Of Memory"
« Reply #21 on: April 22, 2012, 03:30:32 AM »
Quote from: Galleon on April 22, 2012, 02:43:38 AM
Hi pitt,

Quote
I replied the original question of the "ERROR CODE", but still have not gotten a response to what that means. Is there a database of errors and their respective numbers?
Critical Error #1 is a generic out of memory error.

There's a lot of well intended but poor advice being floated around here. I suggest you use your discretion and be selective about what advice you choose to follow.

The whole 148MB (or whatever it may be) seems very unusual to me, especially with your memory specifications.

I'm willing to investigate your program in confidence (I won't share any of your code or content with others) and give you some better informed advice. I recommend you Email it, any supporting files and instructions on how to replicate the error to galleondragon@gmail.com. Without sharing your code with someone you will continue to get well meaning but probably not so useful advice.

I don't want your effort to be wasted either.

Regards,
Galleon

PS. I'm a bit like snail mail on my Email so if you choose to do this don't forget to let me know you sent it.

I know you're the "man", but I have to decline your offer. I think what I will do is during each map transition dump the necessary variables to disk, clear the RAM and then load the contents and write a routine for resuming. At 4KB a step wasted it would take around 30 minutes on a single map to run out of RAM and I'll have to deal with that problem if it even arises as I can also clear the data during a map -> battle transition. I've done a lot of rewriting and clearing of RAM using FREEIMAGE and SPRITEFREE and now the only real issue is the damn map editor and that loop I pasted. I guess I can handle having to restart the program to edit maps every now and then as I don't see how or why I'm getting the error or how to fix it.

Thanks anyway,
pitt

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: "Out Of Memory"
« Reply #22 on: April 22, 2012, 04:09:29 AM »
Quote
but I have to decline your offer
Understood. I've had programs I didn't want to show to anyone else too.

Quote
as I don't see how or why I'm getting the error or how to fix it.
The problem is nor do we. I believe you may have some misconceptions about handles such as that overriding the value of a variable holding a handle will delete the item that that handle is associated with, but I could be completely off base.

I guarantee that the problem you are facing does have a simple and practical solution. Maybe create an array and store all of the image handles you load in the array. Then when it is time for a new map just free all the handles in the array.
Something old... Something new... Something borrowed... Something blue...

SkyCharger001

  • Hero Member
  • *****
  • Posts: 1594
Re: "Out Of Memory"
« Reply #23 on: April 22, 2012, 06:37:50 AM »
Possibility: stack-space is running out in your program.
This could be caused by over-nesting.

Pete

  • Moderator
  • Hero Member
  • *****
  • Posts: 6240
  • Cuz I sez so varmint!
Re: "Out Of Memory"
« Reply #24 on: April 22, 2012, 01:54:33 PM »
The good old days of stack space errors, out of memory that could easily be traced, etc. It gets harder all the time to see how the "old school" of thought applies to all the new additions. Growing pains, I suppose.

Pete
It's only rocket science; it's not Linux!

pitt

  • Full Member
  • ***
  • Posts: 243
    • Email
Re: "Out Of Memory"
« Reply #25 on: April 22, 2012, 03:15:30 PM »
Quote from: SkyCharger001 on April 22, 2012, 06:37:50 AM
Possibility: stack-space is running out in your program.
This could be caused by over-nesting.

Overnesting? Do you mean calling a gosub and not returning to the original after a few calls? If so I've made sure all gosub's and returned and aren't calling out without doing so. I may have the mainloop: (what I call it) gosub to another that gosub's to three more and maybe calls SUB's, but all are RETURN'ed properly. I've quadrouble checked this many, many times during the programming.

Unless that is not what over-nesting means.

Pete

  • Moderator
  • Hero Member
  • *****
  • Posts: 6240
  • Cuz I sez so varmint!
Re: "Out Of Memory"
« Reply #26 on: April 22, 2012, 03:27:42 PM »
In QBasic over-nesting meant just that, calling a sub, which calls a sub, which calls a sub, etc. To many calls and the stack space was used up. Too many GOSUB statements that keep going to other GOSUB statements without returning could do the same thing. But these were problems with a more limited memory system than QB64.

My advice would be to try to isolate part of your code that causes this, if you can. Send that much to the developer, or just post it. As long as only a small part of your program is sent, you are not giving up your application.

Right now, your problem is a newly encountered one, and we simpy do not have a reference to it we can apply as a remedy.

So if you have the time, it would be a win/win for the developer and you if you can figure a way to replicate the problem while protecting your app.

Pete

It's only rocket science; it's not Linux!

pitt

  • Full Member
  • ***
  • Posts: 243
    • Email
Re: "Out Of Memory"
« Reply #27 on: April 22, 2012, 03:38:44 PM »
So I was right. I do have gosub's that call others, but they all return properly. I've checked a lot to make sure they all return correctly as I've run into that problem in the original QB45. I don't branch out more then 4 gosub's and maybe those gosub's call sub's, but I don't have a single SUB that calls another; so gosub's would be the culprit if a single one didn't return correctly.

Okay, so I'm trying to move the "problem" gosub into a sub to isolate the RAM (as suggested), but I do not think I am passing the workscreen(1) and/or backscreen image handles properly.... workscreen(x) is an image array and backscreen is a single image.

This SUB or when it was a GOSUB is called thousands of times in a row to complete the on-screen directional arrows used when drawing boundaries and Action Points.

Code: [Select]
CALL draw_ab(did_ab, show_ab, show_arrows, workscreen(1), backscreen, x$, d$, e, f)
Code: [Select]
' Draw Action Block Lines
SUB draw_ab (did_ab, show_ab, show_arrows, workscreen, backscreen, x$, d$, e, f)

DIM char%(500)
DIM arrow%(500)

IF did_ab = 1 THEN RETURN

IF show_ab = 1 THEN

    IF x$ = "BL" THEN z1 = 255: z2 = 255: z3 = 255
    IF x$ = "SC" THEN z1 = 255: z2 = 55: z3 = 0
    IF x$ = "MV" THEN z1 = 255: z2 = 222: z3 = 0
    IF x$ = "WP" THEN z1 = 255: z2 = 0: z3 = 240

    _DEST workscreen
    char%(90) = SPRITESHEETLOAD("data\images\sprite_global'20x20.png", 20, 20, NOTRANSPARENCY)
    arrow% = SPRITENEW(char%(90), 23, DONTSAVE) ' Make sure SPRITEFREE don't crash by setting an initial sprite to clear

    IF d$ = "D" THEN
        LINE (e - 20, f + 20)-(e - 10, f + 20), _RGB(0, 0, 0), B
        LINE (e - 20, f + 20)-(e - 10, f + 20), _RGB(z1, z2, z3), B
        IF show_arrows = 1 THEN
            IF x$ = "BL" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 7, DONTSAVE): SPRITEPUT e - 15, f + 30, arrow%
            IF x$ = "SC" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 11, DONTSAVE): SPRITEPUT e - 15, f + 30, arrow%
            IF x$ = "MV" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 15, DONTSAVE): SPRITEPUT e - 15, f + 30, arrow%
            IF x$ = "WP" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 19, DONTSAVE): SPRITEPUT e - 15, f + 30, arrow%
        END IF
    END IF

    IF d$ = "U" THEN
        LINE (e - 20, f - 20)-(e - 10, f - 20), _RGB(0, 0, 0), B
        LINE (e - 20, f - 20)-(e - 10, f - 20), _RGB(z1, z2, z3), B
        IF show_arrows = 1 THEN
            IF x$ = "BL" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 6, DONTSAVE): SPRITEPUT e - 15, f - 30, arrow%
            IF x$ = "SC" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 10, DONTSAVE): SPRITEPUT e - 15, f - 30, arrow%
            IF x$ = "MV" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 14, DONTSAVE): SPRITEPUT e - 15, f - 30, arrow%
            IF x$ = "WP" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 18, DONTSAVE): SPRITEPUT e - 15, f - 30, arrow%
        END IF
    END IF

    IF d$ = "L" THEN
        LINE (e - 20, f - 20)-(e - 20, f - 10), _RGB(0, 0, 0), B
        LINE (e - 20, f - 20)-(e - 20, f - 10), _RGB(z1, z2, z3), B
        IF show_arrows = 1 THEN
            IF x$ = "BL" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 9, DONTSAVE): SPRITEPUT e - 30, f - 15, arrow%
            IF x$ = "SC" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 13, DONTSAVE): SPRITEPUT e - 30, f - 15, arrow%
            IF x$ = "MV" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 17, DONTSAVE): SPRITEPUT e - 30, f - 15, arrow%
            IF x$ = "WP" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 21, DONTSAVE): SPRITEPUT e - 30, f - 15, arrow%
        END IF
    END IF

    IF d$ = "R" THEN
        LINE (e + 20, f - 20)-(e + 20, f - 10), _RGB(0, 0, 0), B
        LINE (e + 20, f - 20)-(e + 20, f - 10), _RGB(z1, z2, z3), B
        IF show_arrows = 1 THEN
            IF x$ = "BL" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 8, DONTSAVE): SPRITEPUT e + 30, f - 15, arrow%
            IF x$ = "SC" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 12, DONTSAVE): SPRITEPUT e + 30, f - 15, arrow%
            IF x$ = "MV" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 16, DONTSAVE): SPRITEPUT e + 30, f - 15, arrow%
            IF x$ = "WP" THEN SPRITEFREE arrow%: arrow% = SPRITENEW(char%(90), 20, DONTSAVE): SPRITEPUT e + 30, f - 15, arrow%
        END IF
    END IF
END IF
SPRITEFREE arrow%
_DEST backscreen
END SUB

The end result is nothing drawn on-screen and the program is un-responsive. The workscreen(1) image needs to stay intact between the CALL and END SUB and so does the image handle backscreen. Nevermind the many SPRITEFREE's as in theory if I call a single one at the end the LIB I'm using is supposed to free the RAM for the sprite, but it seems I need to call it each time I use it for it to be effective.
« Last Edit: April 22, 2012, 03:49:41 PM by pitt »

Pete

  • Moderator
  • Hero Member
  • *****
  • Posts: 6240
  • Cuz I sez so varmint!
Re: "Out Of Memory"
« Reply #28 on: April 23, 2012, 08:40:41 AM »
Why do ypu have a RETUN in a sub, when there is no DOSUB statement? If you forgot and moved this from a GOSUB routine to a SUB, then you need to change...

IF did_ab = 1 THEN RETURN

to

IF did_ab = 1 THEN EXIT SUB

Pete
It's only rocket science; it's not Linux!

Clippy

  • Hero Member
  • *****
  • Posts: 16431
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: "Out Of Memory"
« Reply #29 on: April 23, 2012, 08:48:59 AM »
ypu? DOSUB? Proofreading is definitely not your forte...  ;D
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

  • Print