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.

AppGameKit Classic Chat / Tired of AGK

Author
Message
swissolo
15
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 27th May 2014 03:39
Link
Every time I start up a large project in AppGameKit I get ~5 months in or more, and all of a sudden my projects just crash. I must be making a mistake somewhere, but it's impossible to trace when I am given no information. AppGameKit seems to attempt to throw an error and fail. It must have to do with arrays and UDTs, but I've lost the desire to look anymore. I've burned far too much time without any progress. This is the 5th time I've lost a project to this problem has this happened to anyone else?

Back to top
Profile PM
Markus
Valued Member
21
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 27th May 2014 09:28
Link
understand, searching for this kind of errors is no fun.
debugging with print or selfmade breakpoints (sub function enabled by a flag with print and sync), storing
position or last function call in a global udt will help you finding errors/problems faster.
i agree in version < 108 there was much problems in agk that prevent
me from develope a game too.
v2 seems better.

AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon HD 6670
Back to top
Profile PM Email
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 27th May 2014 09:45
Link
I back up my source files every day with a date-stamp. When something that was working stops working I use Windiff to compare the source files to see what was changed in the sub-unit that's stopped working.

It's never the compiler's fault. It's always mine!

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 27th May 2014 11:32
Link
It's something I find no matter what language I develop in. After 6 months or 6,000 lines of code, it can be really difficult to keep the wheels on the track, especially if you start feature-creeping.

TBH I haven't seen any distinct issues in AppGameKit that can't be figured out or worked around... it does help to work with Cliff Melangard though, he's really good at finding bugs. Perhaps when a project get's beyond a certain size, we have to do some housekeeping and stop letting AppGameKit do the media management etc. Like, I wonder if automatically allocating sprites etc is healthy for a big project, maybe going back to numbered ranges like we did with DBPro is an idea. The worst for me was using C++ on an iOS project in Xcode - damn that's one obtuse platform to try and learn from! AppGameKit is like a summer holiday compared to that

I am the one who knocks...
Back to top
Profile PM Email
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 27th May 2014 12:54
Link
I would say that in general projects don't scale as well when using basic. This is the reason much of the practises the basic language uses are not used anymore.

That said, if your project is not planned out in every detail at the start then 5-6 months is around the time it gets messy, no matter what language you are using imo.

Back to top
Profile PM Email
Impetus73
13
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 27th May 2014 13:28
Link
Swissolo, hang on, in June a new beta with the new compiler is hopefully released. Maybe your arrays / UDT's are working better there.

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
Back to top
Profile PM Email
bjadams
AGK Backer
17
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 27th May 2014 14:00
Link
I have 2 projects started in AppGameKit T2 and don't have any problems, so I suppose the problems are related to the T1 compiler. I hope that when the new compiler is done, all will be good for you guys
Back to top
Profile PM Email
baxslash
Valued Member
Bronze Codemaster
18
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 27th May 2014 15:51
Link
I didn't until relatively recently: http://forum.thegamecreators.com/?m=forum_view&t=210064&b=41

This sounds like it might be a similar problem. If it is there's a chance it might be fixed in V2 soon as suggested above.

Personally I don't have this kind of problem in other languages. I'm working in C# so I always get a bug I can track through Visual Studio one way or another. It honestly looks like a problem in arrays to me. I wasn't getting it in V1 but when I moved over to V2 I started getting the problem. Not sure if it was caused by V2 or I just started seeing the bug at that point but I seem to remember reverting for a short while to V1 and the "bug" disappeared.

I've worked in AppGameKit for a long time in Tier 1 and never had this bug before... I can't seem to pin it down to an error in my code either and believe me I always try to do that exhaustively first these days.
Back to top
Profile PM Email
Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 27th May 2014 16:42
Link
Sounds like an UDT array out of bounds, those cause random crashes. AppGameKit doesn't report these and never has. Hopefully fixed soon in v2.

Back to top
Profile PM Website
xGEKKOx
AGK Master
16
Years of Service
User Offline
Joined: 7th Dec 2008
Location: Italy
Posted: 27th May 2014 17:12
Link
I always suggest to move on C++ Tier 2.

Long life to Steve!
Back to top
Profile PM Website
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 27th May 2014 20:01
Link
It's almost always UDT arrays. They are quite buggy in AppGameKit T1. If you access them out of bounds in Windows you will get no message and oftentimes the program will continue to run like nothing happened. Also I found that if you delete / undim an array that doesn't actually exist (say you dim thisArray[] then later undim thiArray[]) then it can delete global variable values... fun. Sometimes UDT arrays have values in them so need to be zeroed out when initialized. Same can theoretically happen with memblocks but I've never experienced it.

99% of the time it has been my mistakes, though some nice error messages sure would help!

Napland Games - Shape Time - Wordspionage - dFenz Facebook
Back to top
Profile PM Email Website
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 27th May 2014 20:28
Link
Those are elementary mistakes, so I think it's a bit tough to blame the compiler.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 27th May 2014 20:49
Link
Yeah, we had this discussion before when I originally brought up my complaints of this. It is a programmer fault. However, when the programmer knows that the compiler will throw an error on standard type arrays being out of bounds they expect to also know of that error when it happens with UDT. Also the parser checks to see if an array was created when you attempt to access the array, by extension it should tell when you undim an array that doesn't exist. Quite silly that it doesn't.

Napland Games - Shape Time - Wordspionage - dFenz Facebook
Back to top
Profile PM Email Website
swissolo
15
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 27th May 2014 21:03 Edited at: 27th May 2014 22:16
Link
I'm sure the issue is something related to my UDT arrays, as I use them often (as a lot of you have said). I've always been extremely careful to avoid what I've found in the past to cause issues, but apparently it isn't enough. One thing I'll try that BatVink mentioned though,
Quote: "I only ever expand arrays, never decrease them. I believe from my experience that increasing them is not an issue. This would suggest a memory leak when removing elements and the old data not being cleaned up."

It's worth a shot.

Quote: "understand, searching for this kind of errors is no fun.
debugging with print or selfmade breakpoints (sub function enabled by a flag with print and sync), storing
position or last function call in a global udt will help you finding errors/problems faster.
i agree in version < 108 there was much problems in agk that prevent
me from develope a game too.
v2 seems better."

Yep. I do have an error log that's come in handy throughout development. So far it hasn't helped me track anything down though. The part of the code that seems to be causing the issue moves depending on what functions I comment out in testing. It's become rather tricky. I think my only chance it to check every array to make sure I haven't missed anything simple.

Quote: "It's never the compiler's fault. It's always mine!"

Quote: "Those are elementary mistakes, so I think it's a bit tough to blame the compiler."

It is always my fault but you can't expect the programmer to never make mistakes. Somehow I sense I have a typo somewhere. I've never been a fan of treating undeclared variables as 0, it always gets me. Regardlessly, the program should never simply crash. We have error reports because mistakes are made If AppGameKit was reporting properly this sort of problem would likely take under a minute to solve.

Quote: "I would say that in general projects don't scale as well when using basic. This is the reason much of the practises the basic language uses are not used anymore.

That said, if your project is not planned out in every detail at the start then 5-6 months is around the time it gets messy, no matter what language you are using imo."

Absolutely. OOP does seem to pay off a lot more over time. My project is actually a pretty good reflection of what I had laid out originally. Of course, minus the bug

Edit: Some of my changes seem to have helped the problem, but not stopped it. The crash now just takes longer to reproduce
Edit2: Apparently, removing this line fixes the problem ._.
The ID is undoubtedly in range, but perhaps my array is somehow corrupt and the value passed into deleteSprite crashes it? I'll find out soon I suppose.
Edit3: Nope. ID:0 bodyID:10035. Does AppGameKit wait to remove sprites at a later time? The only difference I can see here is that this deleteSprite is called close to update(0). (Physics is enabled for these sprites) Perhaps I'll turn physics off entirely first.
Edit4: Nope.
Also crashes. I'd also like to point out the error only seems to occur when I have just altered the sprite's collision bits
Edit5: Interesting.
Does not crash. It seems to relate to removing physics objects. Additionally, the error occurs very frequently if I always alter the collision bits and then remove. It seems that if one of these sprites originally is set to NOT collide with another sprite, in 1 frame is set to collide with it, is removed, and would have collided with the other sprite had it still existed, AppGameKit crashes. I'm going to test my theory by waiting to delete the sprite until after update() and collision check loop.

Relevant Edit: Oh my gosh I was right! So it wasn't my fault after all. Well, perhaps the issue only occurs because of array problems, but I have very few changes left to make. If the project can just crawl the last couple meters I can live with it My code has turned into a complete abomination as I kept all the changes as I went on on the off chance that there were multiple problems. Summary,

set sprite A to not collide with sprite B
sync()
set sprite A to collide with sprite B
ensure that sprite A and sprite B are lined up to collide
delete sprite A
update(0)
enjoy crash or at least for me. I'll have to isolate it later on and see if that's always the case or if my code is cursed.

Back to top
Profile PM
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 27th May 2014 23:24
Link
With the physics engine you have effectively asynchronous processes going on, and I assume plenty of those are queued. It might be a good idea to check if the object is really fully flushed before deleting it.

After what seems like several arduous centuries programming Windows, this kind of scenario is all too familiar. Top of the list is mouse clicks - which get queued. Some users will keep clicking very quickly until they get a response. Nasty things can happen. The first click says "delete this object." So does the second, but the object doesn't exist any more. Boom!

Second on the list is Timer events. Unless you use a multimedia timer the timer events are pushed to the bottom of the queue and can fire at somewhat arbitrary times.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Markus
Valued Member
21
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 28th May 2014 00:49
Link
in agk i often clearing all references too.


AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon HD 6670
Back to top
Profile PM Email
swissolo
15
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 28th May 2014 00:54
Link
^^ I do that as well. It hadn't helped in this scenario.

Back to top
Profile PM
Markus
Valued Member
21
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 28th May 2014 09:02
Link
@swissolo
without source code i/we can only guess what problem it is.

AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265
Back to top
Profile PM Email
swissolo
15
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 28th May 2014 23:55
Link
Quote: "without source code i/we can only guess what problem it is."

Already solved it. I waited to remove sprites until after update() was called.

Back to top
Profile PM
Markus
Valued Member
21
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 29th May 2014 01:18
Link
ok, but can not reproduce


AGK 108 (B)19 : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265
Back to top
Profile PM Email
Impetus73
13
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 30th May 2014 11:26
Link
Why delete anything? I just reuse the assets, and never delete or clears anything. When the app ends, the memory is freed, and I don't think you will ever create an app that will run out of memory on todays phones...

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
Back to top
Profile PM Email
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 30th May 2014 12:22
Link
If you aren't deleting a sprite, you should disable it - because otherwise your left with Box2D collision data laying around, even if you hide the sprite. So, only just hide a sprite if it has no collision settings, if it has collision then disable it as well. And if you have to delete a sprite, don't do it in the main loop, that's just asking for trouble

I am the one who knocks...
Back to top
Profile PM Email
baxslash
Valued Member
Bronze Codemaster
18
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 30th May 2014 15:20
Link
Quote: "if you have to delete a sprite, don't do it in the main loop, that's just asking for trouble"

Really? I've been deleting sprites during gameplay since the start and it never caused me any problems. If AppGameKit is dealing with garbage properly it shouldn't make the blindest bit of difference.

Equally it should be possible to reduce the size of an array at any time. Not using memory dynamically is backwards thinking isn't it? Why keep unused data in memory just to avoid potential bugs in the language? If there are bugs that prevent using the language in a perfectly sensible way they should be fixed not avoided.
Back to top
Profile PM Email
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 30th May 2014 15:54
Link
It depends when you delete the sprite, in Swissolo's case, he was calling a sync(), then deleting the sprite, then calling an update(). IMO that's just gonna cause problems, because update() might assume that the sprite still exists because the sync() has already done its garbage collection.

I think half the problem is that these are issues that AppGameKit tries to deal with for us - like garbage collection. We either do it AGK's way, or we do it our own way, or we don't do anything. Someone or something has to take care of this stuff, if the programmer isn't doing it, then they shouldn't complain about the way it's being done for them. AppGameKit lets us throw code at it however we like, we don't have to think about it very much compared to other platforms.

That's the way I see it at least, we can procrastinate about what AppGameKit doesn't do, shouldn't do, should do, won't do, might do... or we can get on with it and put in our own measures to keep the engine healthy. Damn I sound like an old fart telling people they don't know they're born! - but that's how it feels sometimes. They don't make nerds like they used to! If my 14 year old self was handed AppGameKit all those years ago, I'd happily ask them which nut they'd like in exchange for it.

I am the one who knocks...
Back to top
Profile PM Email
swissolo
15
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 31st May 2014 02:20
Link
Quote: "It depends when you delete the sprite, in Swissolo's case, he was calling a sync(), then deleting the sprite, then calling an update()."

That shouldn't be any different than calling sync() every loop as update() is the first step of sync(). What I shouldn't have been doing it seems is calling update() and then accessing the collision data before render() and swap(). That's a bit disappointing because information from the collisions has to visually lag behind a frame without doing that, but it doesn't seem to be AppGameKit friendly. I don't think I understand what you're saying though if sync() has been called and cleared out evidence of deleted sprites, why would an update() think those sprites still exist? Sync() is the whole package. Once those sprites are cleared it can't be going backwards. Unless of course it's something like what Jim mentioned and the physics thread is causing problems from being misaligned. Maybe I should try disabling to threading and see what happens.

Quote: "Why delete anything? I just reuse the assets, and never delete or clears anything. When the app ends, the memory is freed, and I don't think you will ever create an app that will run out of memory on todays phones..."

Wouldn't it be inefficient to leave sprites sitting around when they're functionally removed? That might be a clever way around the problem (I might try it out if the situation is right haha), but conceptually it doesn't really match up with what is going on in the game world.

Quote: "And if you have to delete a sprite, don't do it in the main loop, that's just asking for trouble"

But once you've entered the main loop everything is effectively in the main loop

Quote: "Really? I've been deleting sprites during gameplay since the start and it never caused me any problems. If AppGameKit is dealing with garbage properly it shouldn't make the blindest bit of difference.

Equally it should be possible to reduce the size of an array at any time. Not using memory dynamically is backwards thinking isn't it? Why keep unused data in memory just to avoid potential bugs in the language? If there are bugs that prevent using the language in a perfectly sensible way they should be fixed not avoided."

We seem to have the same thinking baxslash

@Markus
Perhaps my explanation was poor. That's not really what I meant. I'll try to modify your code to create what I had but I don't know that it will actually recreate the problem

Back to top
Profile PM
xGEKKOx
AGK Master
16
Years of Service
User Offline
Joined: 7th Dec 2008
Location: Italy
Posted: 31st May 2014 20:14
Link
I can't understand this Sync() discussion.
It's a loop, it's called at the end of a screen refresh.
What's the problem with it?

Maybe in the Tier 1 is different?

Long life to Steve!
Back to top
Profile PM Website
swissolo
15
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 31st May 2014 21:06
Link
Quote: "I can't understand this Sync() discussion.
It's a loop, it's called at the end of a screen refresh.
What's the problem with it?"

Sync() is fine (unless some of the other bugs we see happen to occur because of code in sync() ) I'm not really worried about sync() itself. It's when you break it up into update(), render(), and swap() manually. Normally that would be done so you could update your physics realm, maybe reposition a text object or another sprite relative to new coordinates of a physics object, and then draw it to the screen instead of lagging a frame behind. It looks like there may be restrictions relating to what exactly you should be doing between update(), render(), and swap().

Back to top
Profile PM
xGEKKOx
AGK Master
16
Years of Service
User Offline
Joined: 7th Dec 2008
Location: Italy
Posted: 1st Jun 2014 03:57
Link
Ahhh, i undertand.
I had the same problem doing screenshots on iOS, but in the end i understood it and it work.

The problem was the EAGL view that go away on the Swap() so i capture it on the Render().

Long life to Steve!
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2025-05-24 13:33:49
Your offset time is: 2025-05-24 13:33:49