string/integer/array tipping point

[ThirtyNitesOfMX]

using qb64, vista 32 bit os

is there a tipping point in qb64 where you define one too many integers or strings or arrays? this would be sad because im 2/3 done with writing a badass rpg engine.

this is a weird idea, but could it be that i used the letters DEF in my variables which contain Defense information for battle mechanics? qb abbreviates define with DEF, maybe its a bad idea? any thoughts on this would be helpful. id say i have about 1000 variables, a lot of them are 404s for 20x20 tiles and masks. that doesnt seem like a lot of info these days though.. maybe it still is for qb64.

[ThirtyNitesOfMX]

ps. the problem is that i add 1 more variable and it slows down the program drastiacally. i take it back, and its fine again. i also realize that this is the same thing that happens when you define the same variable twice (at least in qb64) and im positive this is not what is happening, im keeping everything really organized.

[burger2227]

Did you change the variable names? DEF might be the problem.

See if removing DEF fixes it. Just change one letter.


Ted

[ThirtyNitesOfMX]

i tried it, naturally, and it semmed to fix the problem.. im just hesitant to rewrite my entire battle system

[burger2227]

Give me some of the variable names you used.

QB64 MAY have a bug that could be fixed.

Ted

[ThirtyNitesOfMX]

i think you're right. i was using lots of variables with DEF in them

like...

dim shared Char1DEF as integer
dim shared Char1MagicDEF as integer
dim shared Char2DEF as integer
dim shared Char2MagicDEF as integer
dim shared Char3DEF as integer
dim shared Char3MagicDEF as integer
dim shared Char4DEF as integer
dim shared Char4MagicDEF as integer

i had quite a few of these.. maybe it would be a good idea to make an error message when people try and use letters DEF in variable names instead of letting them do it and having it slow the program down like it does. try making a simple program where you move a sprite around with the arrow keys with a for next command to slow it down to a reasonable speed, then try the same program with a bunch of these variables declared at the beginning. im not sure if this would prove anything or not unless you also had some DEF SEG commands there too defining your library of graphics as i do. try it and see. i just did and its slowing mine down drastically with each one after about 6.

[burger2227]

I don't see how that could be a problem unless QB64 is misinterpreting it.

YOU CAN change them ALL using the SEARCH menu.

Select Change...

Put DEF only in the top box and a new entry in the bottom. Make sure to select the case sensitive search and click the Verify button to change each entry.

Only the DEF part of the name will be changed.

Let me know if the changes affect the program EITHER way please. We may want to investigate that further.

Ted

[ThirtyNitesOfMX]

it does. i said in my earlier post that i had identified it as the problem, i guess i wasnt very clear. my engine runs smoothly when i change those variables. im guessing im not the first one who has used the letters 'def' in a variable in qb64.. especially considering how many people use QB to make rpg games. should i start a new thread asking if other people have had an issue with this?

[ThirtyNitesOfMX]

Ted, are you one of the QB64 developers?

[burger2227]

I help out at the QB64 Forum. Galleon is the developer, but I put the info in our WIKI.

Now, just to be SURE. You are not doing anything else with DEF in the program that could be interpreted as a keyword.

DEF Fn is NOT supported yet so that would not cause an error. Then you won't be able to use FN in a variable name either like Fname$ for first or file name.

I'll let him know. Thanks

Ted

[ThirtyNitesOfMX]

right. im only using def seg = varseg(variablename(0)) commands

if i remember correctly, in the previous versions of qbasic, when you edited code, it kept track of the lines which had been edited, and then checked those for syntax, keeping the wait time before running the program pretty short, even for long .bas files.. qb64 checks everything, every time, so with a massive program, it takes forever to run it each time you edit something. maybe 7 or 8 seconds.. that time adds up though. is there anything i can do about this?

[burger2227]

People are working on an interpreter, but progress has been slow.

Maybe in another year...

[ThirtyNitesOfMX]

ah i see. well im pretty stoked on qb64 either way. doing stuff i could never do before cause of the 'out of memory' issues.

qb can technically do 32 bit color with the loadimage (Path$, i): screen i

but is there a way to to graphics in realtime, in 32bit, or am i still stuck with what i can put into a 256 color palette?

[burger2227]

QB64 can do 32/24 bit. SCREEN _NEWIMAGE(640, 480, 32) will make a program window in 32 bit. To set the colors use COLOR _RGB(r, g, b) or _RGBA to set the Alpha for clear colors.

It also supports PNG alpha images along with GIF, JPG, and BMP loaded directly to the screen.

See the WIKI for info:

http://qb64.net/wiki/index.php?title=Ke ... phabetical

[burger2227]

ThirtyNitesOfMX would it be possible to get a copy of your program?

Galleon wants to see how it was written before you fixed it if you have a copy of that or can simulate it again.

Please let me know if that is possible. Thanks,

Ted

[ThirtyNitesOfMX]

let me get an email adress and ill it to you