Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / DBPro Compiler Crashes When Loading Large Amount Of Data

Author
Message
Bio Fox
19
Years of Service
User Offline
Joined: 11th Nov 2004
Location: The BioFox Bunker
Posted: 28th Jul 2017 15:44
Hey all, been working on a 2d platforming game which loads collision data generated by Tile Studio. I have four levels of data loaded just fine but when I paste in the fifth level's data set the compiler gets between 75% - 99% then crashes. I've pasted the related code below. My question is if DBPro can handle a couple thousand lines of Data like this? What could be causing the compiler to crash? I'd post the whole game but it is a few thousand lines of code. And Only when removing this section of Data does the crash go away. I've tried shortening the amount of Data for Level 5 but it doesn't seem to do anything. Any help would be appreciated!



Please note I did not not include all the data sets as it is a couple thousand lines. Is it just the shear amount of code/data DBPro can't handle. I've never run into this problem before.

This is the data set that crashes the program:
BioFox Games
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 28th Jul 2017 19:22
Does it still crash if you include only the level 5 data? > could be bad data

If you monitor the compiler process in task manager, how high does the ram use get?

Can you not load it in from external file during run time instead of hard code at compile? > generally a better practice anyway

Make sure you don't have a previous version of the exe still running, you wont be able to compile over it, this has caught me a few times
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Derek Darkly
12
Years of Service
User Offline
Joined: 22nd Sep 2011
Location: Whats Our Vector, Victor?
Posted: 29th Jul 2017 01:07
Like Ortu said, have your tried loading your data from files instead? It's worth a shot.
Send your parents to noisy sprite demo hell... enter the D-Zone
Bio Fox
19
Years of Service
User Offline
Joined: 11th Nov 2004
Location: The BioFox Bunker
Posted: 31st Jul 2017 01:11
Yea, I may have to go that route. Would be easier long term as the code is getting quite long with all the data lines. I'll check the RAM usage during compiling too and post what I find. Thanks everyone!
BioFox Games
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 1st Aug 2017 02:12 Edited at: 1st Aug 2017 02:32
Wow yeah you should really consider saving the data in files. Bloating the EXE like that is not good.
Just pay attention to what type of read and write data type you are using so you don't either waste space or cut off and corrupt values that get too large to be written into the file.
This will also immediately provide you with the benefit of being able to quickly swap data, just load a different file.

Never used DATA statements like that before. I remember seeing those in QBasic like 25 years ago. Oh I see what you are doing.
Yeah don't do that. Do this instead.



Create a series of generic arrays and variables to describe and store the level, it's size, etc. Load a level into that from a file.
What you are doing now is trying to hard code each level into your program and give each level its own arrays and variables. This is not good. If your program was complex you would end up needing to duplicate huge sections of code.
Nobody should be programming like that.
zero32
7
Years of Service
User Offline
Joined: 28th Jul 2016
Location:
Posted: 1st Aug 2017 13:07 Edited at: 2nd Aug 2017 08:05
Quote: "Nobody should be programming like that."

well there is one way this would be a desired way to code: if you want one exe file without any extra files and you do not want to add more levels later, for small games that fit on a usb stick. it would still need directX 9 though.

anyway, looking at the code i see:

so you try to read directly into an array. i had similar problems and i fixed it by doing this:

there is something fishy going on in with the dark basic datatypes and arrays this may be the cause of your problem.

also instead of making an array for each map, i would do it like this:


and add the width and height to the data statements, like this:

and if i want to change the map, i will simply call:

and then do the same as above.

warning, nitpicking ahead:

unlike any other programming language (that i can think of), if you make an array and want it to have 4 elements, you would have to dim arr(3) because the array will have the indices: 0, 1, 2, 3
as opposed to C++ where std::array<int, 3> will only have the indices: 0, 1, 2

it doesn't really matter, but if you want to save some bytes you would need to do:
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 2nd Aug 2017 01:35 Edited at: 2nd Aug 2017 03:36
zero32 wrote: "well there is one way this would be a desired way to code: if you want one exe file without any extra files and you do not want to add more levels later, for small games that fit on a usb stick. it would still need directX 9 though."

I don't think that's a real use case anymore. How small is this USB stick supposed to be? No extra files? Sure but the trade off is massive. Why no files? There's reasons nobody in the professional world does this. It's poor design philosophy. Not only can you not easily change the level data, external programs can't, and you have to load everything into memory at the same time, and the exe becomes bloated which can in some limited cases affect performance. We're not programming embedded microcontrollers here.

zero32 wrote: "also instead of making an array for each map, i would do it like this: [Proceeds to example of generalized data structure for map]"

Exactly you're getting rid of some of the hard coded data structures (some of the ones that hamstring the program the most). Why not get rid of them all?

I just think this problem is only a problem because the whole approach is wrong. He's shooting himself in the foot.
These DATA statements were a necessity back in an era where programs were loaded off of Magnetic Tape, and seeking to try and load files was not feasible.

Bio Fox wrote: "Please note I did not not include all the data sets as it is a couple thousand lines. ..."

Someone has to tell you what's really wrong here and I guess I'm the guy. I hope you figure things out.
Bio Fox
19
Years of Service
User Offline
Joined: 11th Nov 2004
Location: The BioFox Bunker
Posted: 10th Aug 2017 23:43
Yes, thank you for all the feedback. The thousands of lines of data were definitely causing an issue. I originally did it this way because that's how Tile Studio exports the collision data for dbpro. However, I was able to make a small program that reads the data for a level into an array and save the array to an external file using Save Array. Now my game loads all of this data from files using the Load Array function and it works great. No compiler crashes at all! I'll be posting my game to WIP board soon. It's a clone of Little Samson (NES game) that I've been working on for 8 months. Again, thanks for the help!
BioFox Games
Mage
17
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 11th Aug 2017 04:39
It's wonderful to see your quality of life has improved.
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 23rd Aug 2017 15:01
Yeah, the same happened to me when I tried to load too much hardcoded star data.

DBPro compiler can allocate a limited amount of heap memory for generating the exe, therefore file access is the only way to go when dealing with large amounts of data (>2Mb if I remember correctly).

Login to post a reply

Server time is: 2024-03-29 10:29:09
Your offset time is: 2024-03-29 10:29:09