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.

Show posts Menu

Messages - fuzzy70

Another nice looking game there Spicy  :good:, sadly I'm Androidless at the moment  :'(

Well technically not true, other than a really old 2.2 phone which doesn't support GLB programs & not much else either  :D

Odd sensation just using a phone for texts & calls as has been a long while.

If you don't know much C++ like myself then seriously avoid the source code as it will scare the life out of you   :D

Quote from: erico on 2014-Nov-09
Damn those hex crack my mind.

HEX is one of those odd things to get going with, but when "The Penny Drops" so to speak it can make a lot of things easier. Binary is another one, however it can become a bit of a handful when dealing larger numbers as the more digits used the more chance of making a typo & like HEX it makes certain things a lot easier then working in human "Decimal" lol

Off Topic / Re: My programs
That is true from what I recall about the GUI & the duration of the last update, but I honestly can't say when I last used the GUI as normally use either right click context menu or batch scripts for making achives. With regards to updates perhaps they have hit the mark with the compression algorithm they use & can't squeeze any more out of it without compatibility issues arising, doesn't stop them developing the GUI though like you say  :D

Off Topic / Re: My programs
Aha that explains it thanks, I did pop round a friends who has WinRar & extracted it fine. RAR5 files can be problematic with other archive programs hence my problem earlier. BTW I re-compressed the output using 7z for backup & the size was 310MB with standard settings which is half the size, just shows how different archive formats are with different content as normally there is only a +/- 5% difference on average from RAR & 7z in either direction. Both beat ZIP files hands down though that's for sure  :D

Off Topic / Re: My programs
Very generous of you to share  :good:

Out of interest what program did you use to make the archives as I've downloaded the 600 odd MB GLBasic.rar & I cannot extract it. I use 7z & works with all other rar archives I have come across.

I'll see what I can find, I know for a fact though that I have no programs that use jpgs as I rarely use them. One thing that springs to mind is the isometric type landscape using fbm & noise, that's a cpu hogger or my mandelbrot generator is another. Nearly all my other programs don't really do much without user input.

Btw done a test of your program again (same version as I tested last time) but this time booted into windows 7 x64. Left it for around same time as last however memory usage was more than double my previous test & also suffered the black screen from restoring from being minimised. Previous test was done in windows 8.1 x64, same pc & gfx drivers etc just have dual boot.

Welcome to windows lol. No seriously though I have that problem with non glb apps as well & never really got to the bottom of it.

Interesting, I just done a test with the following code
Code (glbasic) Select
LOCAL spritemem%[]
LOCAL loop%

DIM spritemem[76800]

FOR loop = 0 TO 76799


DRAWRECT 0,0,320,240,0x222222



which basically draws 2 rects the same colour, 1 using DRAWRECT & other with a sprite made from MEM2SPRITE & the result was as expected, 2 rects the same colour.

Tested on both Windows & Android.

Well I ran the program for around an hour minimized & when I clicked on the task bar to show it again all was fine as in no black screen but the animation showing as it should.

Memory usage had increased from the circa 40MB at start to around 120MB after the hour so definitely a leak somewhere, however I cannot for the life of me find my tracing program which shows every process/thread associated with a running program (gives way more info than windows task manager/resource monitor).

I did have to stop the program as it was rather cpu heavy, averaging around 50-60% usage, as I needed to do other things on my pc that required the cpu so didn't manage to get to the stage of running out of memory & the error you get.

I have not used a joypad in GLB for quite a while but yes the JOY commands worked fine. Just make sure it's connected before running your program otherwise it might not get detected or you might get some very odd results from the commands.

For some reason that error to me points to something else. Like I said earlier GLBasic uses GCC to compile the final program & all the library files that are used during compilation are GCC ones as VisualC ones are a completely different format & cannot be used in GCC (or vice-versa).

Because of that I can't see how your GLB program can cause a Visual C runtime error as it cant use it hence why I asked if it was your program & not the GLB IDE,which I believe is Visual C++ based judging by the runtimes being installed when you install GLB.

I have had VC runtime errors before (although never with GLB) & that was caused by a conflicting install of either a program or a driver & the solution was done by re-installing the runtime or on a couple of cases windows update had a newer version.

Very interesting problem though.


EDIT: I have just downloaded your program from the 1st post & will see what happens on my system, if the ram leaks I should get an error quicker than you as my test system only has 2GB of ram.
That's interesting, how did you manage to get a Visual C++ Runtime error when GLB progs use GCC?. Or is that error from the GLB IDE

Quote from: Hemlos on 2014-Sep-08

try 0xFF2222 instead

Hex is basically 6 characters long not 8 (not including the 0x part of course)

R G B red green blue  each is 2 chars long

This color should look pink.
MEM2SPRITE colours in array are 8 chars(32bit), 2x each of Alpha, Blue, Green, Red. 0xAABBGGRR.

I should be home soon so will have a look at your code more closely S.O.P.M when there. Also 0xFF222222 is a very very dark gray. Does it look black on windows or android as don't forget nearly all android devices are 16bit colour & not 24bit like pc's etc.

Pretty much 9/10 times if my program just quits it's an out of range array error & I know where to start looking from what was going on before the crash. On the odd occasion where I cannot work out the exact area of the crash then I will normally turn on debugging.

I'm not saying that I am an expert coder who never makes mistakes because I do,  but I coded for so many years without a debugger being available that finding problems/errors in my code is normally a quick process. Also I split my code as much as possible into small chunks of which a lot of routines are reused from other projects which work so that helps me narrow down the cause of any problems.