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 / AGK 108 beta 15 bug??

Author
Message
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 9th Jul 2013 08:01
Link


Pretty simple right? ...Apparently not, the display fubars when displaying on screen like this:


If I move the print and sync under do, it executes like it should



Here's the execution:

I don't get it????? Seemed to work fine on the last "final" build.
Back to top
Profile PM
Matty H
15
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 9th Jul 2013 13:48
Link
Try an extra sync() at the start of your code, see if that fixes it.

Back to top
Profile PM Email
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 9th Jul 2013 13:55 Edited at: 9th Jul 2013 13:56
Link
in the first code snipped there is no sync in loop.
(with sync you must print in loop to see it like your second example)
there is a missing window refresh.
usually the windows os send a paint event...
the desktop/windows paintings share and economize some memory.
Back to top
Profile PM Email
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 9th Jul 2013 16:30
Link
LVNeptune, it is not a bug. It is a usage error.

The Print statement does not create a permanent display. It must be done every Sync() cycle in order to be maintained.

And you must to do a Sync() call at least once in the 'do' loop, otherwise your display never updates.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 9th Jul 2013 19:43
Link
Well, then it's specifically an error in Hands on AppGameKit BASIC.

It specifically states in Chapter 1 that moving the Sync() above the do-loop in such a basic case wouldn't affect the screen output. I will email him about it.
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 9th Jul 2013 20:11
Link
Did it say 'moving' or 'adding'? And was it talking about permanent objects like sprites?

You can call Sync(), in Tier 1, just about anywhere you want to. It will then update the display and retrieve user inputs.

However, you need to do at least a total of two Sync() calls to make sure that everything you do is displayed, if you don't do regular Sync() calls.

I tested your code by adding a second Sync() after the first (from your first code post) and ended up with a blank screen without the print strings. Which is correct. The settings for the basic display were applied and the screen was updated.

But, as mentioned before, a Print statement is not permanent. If you had created a sprite and displayed it, it would stay in the display without the Sync() calls in the 'do' loop (assuming you did two Sync() calls after adding it).

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 9th Jul 2013 21:34
Link
i belief it was not the screen refresh, i think agk need one Sync before
and did have something visible on screen over the text output.
Back to top
Profile PM Email
Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 9th Jul 2013 22:04
Link
There is nothing wrong with LVNeptune's code. My guess is that in the first example the screen buffer is either not empty or it is the wrong size. Once the first sync() has been called, this is no longer the case.

Back to top
Profile PM Website
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 9th Jul 2013 22:05
Link
Markus, that does work. I was wrong (not the first time and won't be the last). The order of the Sync() calls makes an apparent difference. I did not try that combination.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 9th Jul 2013 22:12
Link
@Ancient Lady
no, i just try two syncs because the background was not white
and if u drag the window out of screen the rest of the text was not
deleted. it looks like there is some initialization from agk before.
Back to top
Profile PM Email
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 9th Jul 2013 23:31
Link
OK. So you are saying that when the Sync() call is issued it isn't clearing the buffer completely as the buffer memory is shared between Windows Apps? But when it's issued in the do-loop it continuously keeps refreshing it so that's why it works?

That kind of makes sense.

Why would it still work if you issued two Sync() calls though without the do-loop.

This just seems odd to me. Shouldn't AppGameKit clear the buffer on init or even exiting the app?
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 06:16 Edited at: 10th Jul 2013 06:50
Link
So I went ahead and took a screenshot of the two pieces of text in question.




I'm thinking it was just an error on his part because if you run it as he says in that order it would technically work. The first code being "proper" then when you run the second code, even though it technically isn't working as it should, the previous code is still in buffer. That sound about right?
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 09:26
Link
OK....I definitely think there's an issue here. Why is AppGameKit returning extra decimal places that were never defined? I just emailed this to Alistair.

I think there is an issue with the AppGameKit Player beta. You wrote a lot of your code like that and I seriously doubt you messed up and no one else noticed this far along.



Pg 78.:



name$ = "Charlotte"

weight# = 95.3

Print(name$)

Print(weight#)

Sync()

do

loop





Returns a black screen which is probably a left over buffer or something from what I had on there previously. Obviously moving the Print() and Sync() into the do-loop works.



Except, when running the code it says Weight = 95.300003 instead of just 95.3 ....Am I doing something wrong???
Back to top
Profile PM
AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 10th Jul 2013 09:32
Link
@LVNeptune When the second chapter of Hands ON AppGameKit was written (about two years ago), that version of AppGameKit ran the code you used
(with a single SYNC() call outside the do..loop structure)quite happily. Now it seems to be a problem.
I suspect there is some sort of bug in Sync()somewhere. Below is an even stranger example of the bug. The code draws a random selection of dots but these only appear on part of the screen unless you comment out the CreateText() line.
Back to top
Profile PM Website
AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 10th Jul 2013 09:56
Link
Sorry, I meant, remove the comment characters (//) from the CreateText() line.

I've also found that if you add a Sync() statement as the very first line of your program, everything works fine, so, again, it looks like a single call to Sync() doesn't do everything it should.
Back to top
Profile PM Website
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 10:08
Link
Actually, if I add Sync() as the very first line in anything the .exe crashes

The program Name.exe version 0.0.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
Process ID: 528
Start Time: 01ce7d3bf8955be6
Termination Time: 18
Application Path: C:\Users\Neptune\Documents\AGK Projects\Name\Name.exe
Report Id: 3b252f8f-e92f-11e2-bf49-d4bed9617e7c
Faulting package full name:
Faulting package-relative application ID:
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 10:13
Link


This crashes. Every variation with Sync() in the beginning will crash. As soon as I remove it, works fine. Seems that the interpreter is having some issue with Sync()



Executes fine.

also, the GetRawState I obviously added just to close out of the apps easier.
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 10:15
Link
Argh, sorry for the constant posts but unfortunately I can't edit my previous ones because they don't show up instantly >_<



Crashes every time as well. No Sync() causes it to crash just the same as if there was a Sync() on the first line. Hopefully some dev sees this and chimes in.
Back to top
Profile PM
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 10th Jul 2013 17:00
Link
LVNeptune, I may be way off here and apologies if I am. Of all the examples I've seen with if/then they are always on the same line. I don't use if/then, so am not sure if what you have done is fine, but what happens if you move the exit in line with your if/then statement? i.e.

Back to top
Profile PM Email
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 10th Jul 2013 17:14
Link
LVNeptune, I'll back up to your earlier post with the images (you used the code tags for a couple of images of pages in the book).

What wasn't working in the first one? Other than the two lines appearing on the same line (you used PrintC) and the letters being scrunched way close (you set the print spacing to a negative value). I tested the code and it looks like what the code says it should (pretty odd, but correct).

In the second case, that is a code mistake. It would work if there was a Sync() call before the first PrintC command.

But AlistairS is correct, in v1076 the code does produce the text output, even if the background color is black instead of red.

Your issue with the floating point print adding extra decimal points is that, internally, floating points aren't exactly the numbers you think. Unlike integers, which are represented purely by binary bits, a floating point value is comprised of bits that are calculated to produce the number entered. There is a longer discussion about this somewhere in the forum. It is why you don't compare float variables to exact numbers.

I tested both of the versions you say crash and neither did for me.

What version of AppGameKit are you working with?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 18:48
Link
It crashes on the build in this title which is 108 beta 15 which was released a few days ago.
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 10th Jul 2013 18:56
Link
Did you do a fresh install for v10815 or did you install over an older version?

I install each version in its own directory so that I can test different versions to see when a bug appears (or disappears). I keep all of my own projects in directories outside of the AppGameKit trees.

As I said, I had no trouble compiling your code at all.

I suspect you may have a corrupt installation.

What version of Windows are you using?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 19:10
Link
Windows 8. Just tested the crashing code on a different PC with Windows 8 and it executes fine. Also, I did install it over another version. Installed the older version. Deleted the folder (since there's no uninstaller) installed it again. Keeps crashing on that one PC.
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 10th Jul 2013 19:42
Link
It now sounds like there is an issue with your PC. And, without sitting in front of it, it is hard to try and figure out what the problem is.

Sorry, it looks like I am out of help for this problem.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 10th Jul 2013 20:01
Link
Eh...Still doesn't explain all the other weirdness. Especially since the code normally executes fine unless I add the Sync() in the first line. I bet a PC reboot will fix it temporarily. I think it has something to do with the front/back buffers that AppGameKit is using.
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 10th Jul 2013 21:11
Link
I just created a fresh project and entered the same code you show for the one that crashes for you (with the Sync() call as the first line).

It compiled just fine and ran just fine. No problem at all.

This really does seem to indicate that the issue is either with your install, Windows 8, or both.

Initially you were saying the code was crashing when you compiled it. Now you seem to mean that it crashes when you run it. Which is it?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 11th Jul 2013 00:18
Link
Sorry if it came across that it was crashing on compiling. It was crashing executing. I could always compile.
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 11th Jul 2013 00:28
Link
Okay. It compiles and runs fine on my PC.

Can you run the compiled app independent of the IDE?

By that, I mean open File Manager (assuming that it still exists in Windows 8) and navigate to the directory that has the project that is crashing. Double click on the <myprojname>.exe file and see if it runs.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 11th Jul 2013 04:27
Link
Heh...Now the code is running. PC hasn't even been rebooted. However



Crashes with Sync() in the first line but not in the do-loop. So weird. And that code crashes in 1076 as well as 10815
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 11th Jul 2013 05:25 Edited at: 11th Jul 2013 05:25
Link
Do you have two separate installations for v1076 and v10815? (I have v1076, v1082-5, v1088-15 as separate installs).

In all my tests at this point I am running directly from the 'compiled' exe in File Manager and not from the IDE. There are some known issues with it sometimes getting hung when you try to close an app run from the IDE.

And the code you just posted doesn't crash, but it does get get caught in some loop and hangs with the whirly thing indicating that it is trying to process something (because it has no way to get the key state or update or anything without the Sync() in the do loop). Is that what you mean by 'crash'?

I get the same behavior with v1076 and v10815. But it does not crash. That appears to be something due to Windows 8, is my guess.

If I properly put the Sync() in the 'do' loop, both work fine. Which is to be expected because it now can update the display and check for key (or other) input.

Putting a Sync() call as the first command is useless and serves no purpose at all because you haven't done anything to create a display.

Putting a Sync() call somewhere in your 'do' loop is the correct way to do things. I think the examples in the book were meant just to show a point, not to show what you would normally do. And they don't apply to v108+ versions.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 11th Jul 2013 06:55
Link
"And the code you just posted doesn't crash, but it does get get caught in some loop and hangs with the whirly thing indicating that it is trying to process something (because it has no way to get the key state or update or anything without the Sync() in the do loop). Is that what you mean by 'crash'?"

Yes. The app is not responding the only way to exit is force close, which is because the application crashed. It seems your definition of crashing is different than the rest of the internet.

http://en.wikipedia.org/wiki/Application_crash

"A crash (or system crash) in computing is an event in which a computer or a program (such as a software application or an operating system) ceases to function properly, often exiting after encountering errors. Sometimes the offending program may appear to freeze or hang until a crash reporting service documents details of the crash. If the program is a critical part of the operating system kernel, the entire computer may crash (possibly resulting in a fatal system error)."
Back to top
Profile PM
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 11th Jul 2013 09:45
Link
It's absolutely bound to hang because it's badly programmed. It's in a loop which does nothing. Without a sync() in the loop nothing whatsoever will get processed. Ergo : infinite loop with no exit condition.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Back to top
Profile PM Website
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 11th Jul 2013 16:30
Link
When people say 'crash', I assume that it fails at some point and stops.

Hanging is a different thing. Even if it is included in the description you quote.

So, the program is acting exactly as expected given the code. What is the surprise there?

This is not a bug, it is bad programming.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 11th Jul 2013 17:22 Edited at: 11th Jul 2013 17:23
Link
To be fair to LVNeptune, the Sync() should really be called Update() because it does a lot more than a buffer swap. That's probably why Erik van Bilsen hid Sync() away in the OnUpdate() method in AppGameKit Pascal.

In Delphi (for example) it is vital in tight loops to ensure an exit condition:

While NotCancelled do
begin
// do some stuff
Application.ProcessMessages; // we assume a keypress or mouse click will set NotCancelled to false;
end;

Without that message processing the program will hang and report "not responding."

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Back to top
Profile PM Website
unlikely
12
Years of Service
User Offline
Joined: 5th Mar 2012
Location: Ohio, USA
Posted: 11th Jul 2013 18:19
Link
Quote: "To be fair to LVNeptune, the Sync() should really be called Update() because it does a lot more than a buffer swap."

Aside from the fact that there is already an Update()

Sync() is really just calling Update() Render() Swap()... shortcut method, yeah?
Back to top
Profile PM
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 11th Jul 2013 20:55
Link
Yep - but it also does the input polling.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Back to top
Profile PM Website
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 12th Jul 2013 00:05
Link
Yes but you are missing the point. Without Sync() in it AT ALL it loads and closes without issue. When Sync() is thrown in as I showed it crashes, hangs, whatever you want to call it.

At this point it's just an annoyance.

As Alistair posted earlier

"@LVNeptune When the second chapter of Hands ON AppGameKit was written (about two years ago), that version of AppGameKit ran the code you used
(with a single SYNC() call outside the do..loop structure)quite happily. Now it seems to be a problem.
I suspect there is some sort of bug in Sync()somewhere. Below is an even stranger example of the bug. The code draws a random selection of dots but these only appear on part of the screen unless you comment out the CreateText() line. "

It doesn't work now. So either that was by design or it's been a long standing bug that hasn't been rectified.
Back to top
Profile PM
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 12th Jul 2013 01:27
Link
I give up.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 12th Jul 2013 01:29
Link
Don't be daft. Without a Sync() anywhere it will exit neatly having done nothing.

Put a Sync() in the loop. That's all it needs. How hard is that?

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Back to top
Profile PM Website
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 12th Jul 2013 01:54
Link
JimHawkins, he's not caring about how it should be done. He's complaining about something that simply doesn't work.

And the code he shows will compile and create something that starts. But it cannot be closed properly, no matter what version of AppGameKit you build it in. It will always hang on the close-by-click-on-X, or hang on its own if left open long enough.

If there are no Sync() calls at all, the app opens and closes (by click on X) without complaint.

If you put a single Sync() at the start of the app, it hangs/crashes when you try to close it.

His original complaint was somewhat justified. The Hands on AppGameKit Basic book listed an example that did work in v1076 but doesn't work in v10815.

He took pictures of the two code examples in the book. This one works just fine in all versions. But this one worked in v1076 but no longer works.

Once that was cleared up, he went onto the 'issue' encountered by lots of people regarding the exactness (or lack of) of floating point representation (my words).

Then he tried adding a Sync() as the first line in his test code and it caused the hang/crash issue. This was something he came up with on his own, not from the book.

Since it clearly causes a problem and is not proper programming in AppGameKit to start with, it just shouldn't be done. And that really should be the end of this discussion.

Since the developers never expected anyone to do such a thing, since it serves no purpose at all, they didn't write it into the system.

I'm not trying to be nasty. But repeatedly going over the same point just to be arguing about it gets frustrating.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
LVNeptune
13
Years of Service
User Offline
Joined: 17th Sep 2010
Location:
Posted: 12th Jul 2013 02:43
Link
Agreed. We can just go ahead and drop this now.
Back to top
Profile PM
Impetus73
12
Years of Service
User Offline
Joined: 28th Aug 2011
Location: Volda, Norway
Posted: 18th Jul 2013 22:10
Link
I don't get it, why is it not working, please repeat all, and SLOW, and in more detail AL *joking*


do
loop

= walk around in circles forever until you drop dead.

----------------
AGK programmer
Did Amiga / AMOS programming in the 90's.
Back to top
Profile PM Email
AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 21st Jul 2013 19:16
Link
Can I just clarify that the problem with the results produced when running the examples from the Hands On AppGameKit BASIC book are caused by a fault with the current implementation of the Sync() statement.

I've shown Lee the code examples running and he agrees that it's a problem with AppGameKit BASIC so hopefully there will be a fix in the next release.

However, no doubt there will be things in the book that eventually need updating and I am hoping that the community will give me the feedback I need to make the required changes to the book. For example, someone has already been kind enough to tell me that automatic splash screens no longer work and I will update the book to reflect this change.
Back to top
Profile PM Website
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 22nd Jul 2013 05:04
Link
Quote: "automatic splash screens no longer work"

Since when?

My Android v10815 project very nicely does the AGKSplash.png file, in landscape even.

I don't use it in any of the other platforms because it isn't necessary. Apple has its own default start up images for iOS. And Mac and Windows load so quickly that you never see the AGKSplash.png, if it is there.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Back to top
Profile PM
AlistairS
11
Years of Service
User Offline
Joined: 28th Apr 2013
Location: U.K.
Posted: 22nd Jul 2013 09:19
Link
The splash screen comment derives from my tests on a Windows machine and Paul's comments in another thread:

I'd recommend against using AGKSplash.png right now as I'm probably going to deprecate it and advise using a splash screen at the start of your code instead. The point at which the splash screen is displayed is before you set your virtual resolution, orientation, etc, which messes things up, so it's best to display a splash screen yourself after you've set this up.


When I first wrote those early chapters of the book I'm fairly sure I could see the splash screen on my Windows machine.
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2024-05-02 11:18:59
Your offset time is: 2024-05-02 11:18:59