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 - bigsofty

Pages: [1] 2 3 ... 177
1
GLBasic - en / Re: Pegasus and the Phantom Riders
« on: Today at 04:28 AM »
Joust was one of my favourite arcade games!

Its a classic with some remarkable sophisticated physics for its day.

Good choice Erico!  :good:

2
Off Topic / DAW for game music
« on: Today at 03:06 AM »
Anyone here using a DAW for there music?

If so could you recommend one and give your reasons why?

I'm looking into it but my head is spinning with the different ones available.  :S

3
Off Topic / Re: Steam Deck
« on: 2021-Jul-23 »
I have pre-ordered but it took a ridiculous amount of effort as the order page was overwhelmed by demand.

4
Off Topic / Re: Steam Deck
« on: 2021-Jul-18 »
it looks like standard PC hardware, so Windows should go on it no problem. Personally i'd multi boot it with Steam OS and Windows for maximum compatibility.

5
Bug Reports / Re: Norton .exe complain
« on: 2021-Jun-23 »
Nice advice Qedo, I'd forgotten about Virustotal, its a great quick fix for anyone with false positive nervousness.

6
Bug Reports / Re: Norton .exe complain
« on: 2021-Jun-21 »
Norton is pretty notorious for false reporting, it may not be your fault Erico. Maybe recommend a decent anti-virus e.g. ESET Nod32.

7
Announcements / Re: New BETA
« on: 2021-Jun-15 »
Cool, thank for your support Gernot!  :)

8
Yes the code is much more modular and structured.

Beware though, GOTO was invented by the devil!  ;)

9
This looks cool, quality work as usual Darmakwolf!  :good:

10
Well done Hemlos, very interesting work!  :good:

11
That's the last error message squashed well done Gernot!  :enc:

As you can tell this is quite a relief, I've a very large project and I was was trying to keep proper working hours with it. So each day missed was a days work lost. But all's good now, I can jump back in.  :good:

One thing I noticed here though, is that maybe I should take more of an active roll in beta updates. If there is any beta updates posted in the future, drop me a message please and I'll happily run it through my behemoth of a project to test the compiler and also provide some feedback.

12
I just tried the code I posted(The full TMaterials type in Reply #3 above) on the beta GLBasic Precompiler V.17.312 and it compiles, which is great!  That very reassuring TBH. =D

I haven't executed it as its pretty out of context but the Precompiler usually does an excellent runtime error prevention I'm sure it will be fine.

Seems "self.F" above is still causing further errors though.




EDIT:

Here is the modified type showing the ".self=" error...

See... "FUNCTION AddBuggedFunc:"

Code: (glbasic) [Select]
TYPE TMaterials

filename$
totalMaterials%
m[] AS TMaterial

FUNCTION SetUp:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION Update:
self.totalMaterials%=LEN(self.m[])
ENDFUNCTION

FUNCTION Render:
ENDFUNCTION

FUNCTION Destroy:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION ReadFile: filename$
LOCAL f%,l$
LOCAL n%,t$[]
LOCAL i%
LOCAL m AS TMaterial
self.Destroy()
self.SetUp()
f%=GENFILE()
OPENFILE(f%, filename$, TRUE)
//DEBUG "Start read TMaterials.ReadFile("+filename$+") file >\n"
REPEAT
READLINE f%, l$
n%=SPLITSTR(l$,t$[]," ")
IF LEN(t$[])=0 THEN CONTINUE
SELECT t$[0]
CASE "newmtl"
DIMPUSH self.m[], m
self.m[-1].name$=t$[1]
CASE "Kd"
self.m[-1].red# = t$[1]; self.m[-1].green# = t$[2]; self.m[-1].blue# = t$[3]
CASE "Tr"
self.m[-1].alpha# = t$[1]
CASE "Ns"
self.m[-1].size# = t$[1]
CASE "#"
DEFAULT
ENDSELECT
UNTIL ENDOFFILE(f%)

FOREACH m IN self.m[] // <------------------- THIS IS LINE 82
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT
//DEBUG "< End read material file\n"

CLOSEFILE f%
ENDFUNCTION

FUNCTION GetMaterialIndex%: findname$
LOCAL matIndex%=0
FOREACH mat IN self.m[]
IF mat.name$ = findname$ THEN BREAK
INC matIndex%
NEXT
IF matIndex%=LEN(self.m[])
// myDEBUG ( "Error in GetMaterialIndex(): Material '"+findname$+"', not found!\n" )
END
RETURN -1
ENDIF
RETURN matIndex%
ENDFUNCTION

//*************************************** ERROR ************************************

FUNCTION AddBuggedFunc: matArray[] AS TMaterial
self.m[] = matArray
ENDFUNCTION

//***********************************************************************************

ENDTYPE


TYPE TMaterial
name$
red#
blue#
green#
alpha# = 1.0
combined% = 0xffffffff
size# = 32
text$[]
ENDTYPE


13
 The Steam version (not beta) is GLBasic Precompiler V.17.200, this is the current Steam Release version, that was updated at the weekend to  V.17.200.

... I just downloaded the beta which is GLBasic Precompiler V.17.312. I am now getting a new error.

"protoList.gbas"(73) error : GPC0007 wrong argument type :

Code: (glbasic) [Select]
FUNCTION SET_F: F[] AS TGOProto
self.F = F // <------------ This is line 73
ENDFUNCTION // Full array swap

F[] is just an array within a type.

I must stress that I haven't used this Beta, the last one I used was a couple of weeks ago and I was getting some errors then. I will mirror what you have done Gernot and do a separate compile on the previous code to see if that piece of is now compiling on the new beta.

14
Thank you SnooPI and thank you Gernot, your support is really appreciated.  :booze:

Now, thew, bare with me please! :) Just be be clear, this is a new bug in the compiler that was introduced when an attempt was made by you Gernot to change the behaviour in the compiler of when dealing with ".self" a couple of weeks back. My code I am showing here is years old and has worked fine up until Sunday when I downloaded the latest Steam release patch.

Also I will do as you ask and modify my code around this error(we already did this in the previous thread) but, please be patient with me, I am a little unclear why? This is only something that was introduced after a failed attempt to add functionality to the compiler, wouldn't it be easier to simply roll back this part of the compiler code to where it was working fine? No functionality would be lost. This should affect Shoebox for example.

The reason the I would declare(not so much in this sub) the iterator variable, for use in a FOREACH block is because of scope. Logically the declaring the variable as a LOCAL(or even on a global) outside of FOREACH block means that it will be used somewhere in else within the function. If I had use an IF/THEN/BREAK within the FOREACH then I would not want scope errors when trying to access "w" outside the FOREACH block, in this case. This used to work fine, so there is actually a loss of functionality when working around this bug.

Again, to reiterate, this is not a new compiler bug, it's one that's been introduced with the previous beta and with no added functionality to the compiler, simply rolling back the code pre ".self" modification hopefully this shouldn't add any bugs as it was a new bug introduced to old compiler code only a couple of weeks back.





EDIT:

I did the modifications as asked and now this is not working...

"material.gbas"(82) error : GPC0007 wrong argument type

Code: (glbasic) [Select]
FOREACH m IN self.m[] // <------------------- THIS IS LINE 82
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT

I'm feeling a little dejavu here ;) These are the same modifications you asked me to make to the same code when the bug was introduced in the last beta(see here a couple of weeks ago... https://www.glbasic.com/forum/index.php?topic=11453.msg101179#msg101179 )

Here is the full type by the way(which again, was years old working code)...

Code: (glbasic) [Select]
TYPE TMaterials

filename$
totalMaterials%
m[] AS TMaterial

FUNCTION SetUp:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION Update:
self.totalMaterials%=LEN(self.m[])
ENDFUNCTION

FUNCTION Render:
ENDFUNCTION

FUNCTION Destroy:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION ReadFile: filename$
LOCAL f%,l$
LOCAL n%,t$[]
LOCAL i%
LOCAL m AS TMaterial
self.Destroy()
self.SetUp()
f%=GENFILE()
OPENFILE(f%, filename$, TRUE)
//DEBUG "Start read TMaterials.ReadFile("+filename$+") file >\n"
REPEAT
READLINE f%, l$
n%=SPLITSTR(l$,t$[]," ")
IF LEN(t$[])=0 THEN CONTINUE
SELECT t$[0]
CASE "newmtl"
DIMPUSH self.m[], m
self.m[-1].name$=t$[1]
CASE "Kd"
self.m[-1].red# = t$[1]; self.m[-1].green# = t$[2]; self.m[-1].blue# = t$[3]
CASE "Tr"
self.m[-1].alpha# = t$[1]
CASE "Ns"
self.m[-1].size# = t$[1]
CASE "#"
DEFAULT
ENDSELECT
UNTIL ENDOFFILE(f%)

FOREACH m IN self.m[] // <------------------- THIS IS LINE 82
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT
//DEBUG "< End read material file\n"

CLOSEFILE f%
ENDFUNCTION

FUNCTION GetMaterialIndex%: findname$
LOCAL matIndex%=0
FOREACH mat IN self.m[]
IF mat.name$ = findname$ THEN BREAK
INC matIndex%
NEXT
IF matIndex%=LEN(self.m[])
myDEBUG ( "Error in GetMaterialIndex(): Material '"+findname$+"', not found!\n" )
END
RETURN -1
ENDIF
RETURN matIndex%
ENDFUNCTION

ENDTYPE


TYPE TMaterial
name$
red#
blue#
green#
alpha# = 1.0
combined% = 0xffffffff
size# = 32
ENDTYPE

15
Looks like the test modifications, that should have been removed, that I tested a few weeks ago (see my posts regarding the removing ".self" compiler modification in Steam beta) have now made there way in the the the actual newly updated Steam version of GLB!?!? See... https://www.glbasic.com/forum/index.php?topic=11453.msg101179#msg101179 post.

I now simply cant compile my code. I tried to modify around this error but my project is over 150 thousand lines of code, spread across 129 files... and gave up after an hour.

Obviously this was compiling fine before the update last week.

"gui.gbas"(1685) error : GPC0007 wrong argument type

Code: (glbasic) [Select]
FUNCTION GetWidgetID%: name$
IF name$="" THEN RETURN -1
LOCAL i%, w AS TWidget
FOREACH w IN self.w[]
IF name$=w.text$[WB_NAME_STRING] THEN RETURN i%
INC i%
NEXT
RETURN -1
ENDFUNCTION

Its the same piece of code that was tested here(https://www.glbasic.com/forum/index.php?topic=11453.msg101179#msg101179) after the test modification was made to the Steam beta compiler which has made its way into the release build. This was supposed to be dropped for causing these errors a few weeks ago. Unfortunately, this is only the first of a lot of of compiler errors now in my code.


Pages: [1] 2 3 ... 177