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.

Android / [SOLVED] is SetClearColor() implemented on Android?

Author
Message
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 1st Nov 2021 23:15



works on Windows, but on Android (Pixel 4a running Android 12) the screen clears black.

Any suggestions?

BTW I have used the search feature to search the forum for SetClearColor in the Android section and it found zero hits. I suspect search is not working well because earlier I searched for JDK and found none, yet it is mentioned in a sticky post !

The author of this post has marked a post as an answer.

Go to answer

Virtual Nomad
Moderator
17
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 1st Nov 2021 23:29 Edited at: 2nd Nov 2021 00:07
forum search only searches thread titles. if i'm really digging for something, i use google site search

( just realized that you probably meant to search thread titles (only) )
Quote: "is SetClearColor() implemented on Android?"

yes. what does this do for you?

(should just be a red screen)
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 02:29 Edited at: 2nd Nov 2021 02:32
I now have more details on this issue.

The AppGameKit player always displays the issue. An installed APK initially works as expected, until one switches to another app and then returns to the app. At that stage it looks just like it does in the AppGameKit player.

Here is the screen before switching to another app:


After switching away and returning to it:

The second image is how it looks in the AppGameKit player without switching.

So it may have something to do with 'internal automatic' screen refreshed that does an implicit screen clear.

I liked your suggestion of calling SetClearColor() in the main loop.... thinking that the internal clearing of the screen would pick up the desired color, but nope...
I threw in:

but the AppGameKit player still shows black areas that should (now) be gray. Windows shows gray as expected (even if the window is resized) showing that the SetClearColor() is being called. However, the AppGameKit shows black
and an installed apk shows the gray until the app loses focus and on return, it is black again. So the internal code is not picking up the set colors, but using zero values instead.

Windows with 207,207,207 call
Virtual Nomad
Moderator
17
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 2nd Nov 2021 02:55 Edited at: 2nd Nov 2021 02:56
so all the blue is comprised of a number of "background" sprites? are you rendering to image(s)? and, review EnableClearColor() for potential leads.

otherwise, i'm trying to understand the "tiled" ill-effects. can you provide some simple code to replicate the issue?

meanwhile, since it's sounding like the issue lies in returned focus, perhaps resetting any display/render settings on GetResumed?

Quote: "I liked your suggestion of calling SetClearColor() in the main loop"
did i? i didn't mean to i don't expect it's a healthy thing to do.

again, does:

(continue) with a (solid) red screen when focus is returned?
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 14:45
I'll make a minimal sample project to demonstrate it and also try your exact code snippet. What I did was place an additional SetClearColor( 207,207,207 ) within the loop that calls sync() and it still did not fix it.
I'll also try and look for a workaround using GetResumed. I did look at EnableClearColor() but did not try forcing that to true explicitly.

My screen is made up with numerous EditText boxes that are inactive. The colors and text that displays is sent over a TCPIP connection. All the background areas that are not blue is the screen background that should be blue.
Virtual Nomad
Moderator
17
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 2nd Nov 2021 15:04 Edited at: 2nd Nov 2021 15:05
that helps. thanks for that.

have you tried Update(), Render(), Swap() to manually sync?

can't say i've seen Swap() followed by Sync() (but i don't pretend to understand much to do with manual/hybrid Syncing).

another workaround would be to use a background sprite that fills the screen with (whatever) color.
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 15:06 Edited at: 2nd Nov 2021 15:31
Edit: ignore this post completely, I have found how to reliably reproduce it, will post sample code and steps to show the problem soon.

so far, my demo project is behaving perfectly, so there is something else in my project causing the problem. I am looking for what that might be... I hope it is not the number of EditText boxes.

In the meantime:



displays a red screen as expected.
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 15:54
The problem arises if the app loses focus once. Once it regains focus the screen background is always black. This happens in both an .apk and the AppGameKit Player

Note that the player app just has to lose focus once, and once that has happened even new broadcasts suffer the problem. To get SetScreenColor() to work again one has to exit the player and start it again. (This is why yesterday I thought the Player was behaving differently to an .apk)

My sample code includes three buttons to show that SetScreenColor() does indeed (repeatedly) work initially.
Sample code:


To witness the problem;
1) broadcast the code to Android (or install an apk of it)
2) click on the three buttons, background will change accordingly.
3) Switch away from the app
4) Switch back

On my Pixel 4a running Android 12, the screen is already black at that stage.

If you tap any of the buttons you see they change their shade as if the background had changed. This tells us that the button code is being executed.

Adding

does not make a difference.

Perhaps this is a new behavior with Android 12 that people have not ben running into this problem more.
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 16:00
the minimal code by Virtual Nomad also demonstrates the issue, one has to switch focus to reproduce.



Red initially then black after switching away and back.
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 16:11
now, to answer the question:
Quote: "have you tried Update(), Render(), Swap() to manually sync?"


yes, I added one of the alternate methods to each button as follows:



With no improvement.

Since we are explicitly setting the color, and forcing a screen clear I am not sure how GetResumed will help us (other than to know that the app is now broken!)

I will describe the problem on GitHub.
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 16:47
This post has been marked by the post author as the answer.
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 17:24
oh shucks, I just noticed that after doing searches, I ended up posting issues in AppGameKit Studio
instead of https://github.com/TheGameCreators/AGKIDE

Must I redo them? My bad.
Virtual Nomad
Moderator
17
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 2nd Nov 2021 17:49 Edited at: 2nd Nov 2021 18:05
no, that's perfect where it's at. i'll tag it up when i'm done with this post.

earlier you mentioned #renderer "Basic" so i assume it's happening on both classic and studio for you? (2021.10.19 is Classic)

meanwhile, that's not what i meant by using Update(), Render(), Swap() (without Render and separately, followed by a Sync() as in your 3 button code).

you started with

and i still don't understand why you're adding ClearScreen() or Swap(). regardless, the latest code doesn't and the issue remains as an OnResume notion.

i mentioned using a "background" sprite. how does this work for you?

again, i don't know all that you're doing so dunno if that's a viable work-around. see also EnableClearColor()

meanwhile, i have zero issues on resume (while opening/switching between multiple apps and back) while broadcasting any of the code above thus far on my old samsung J3.
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 18:21
thanks, I have not turned my attention to finding a workaround just yet so I will try your suggestion soon. I was planning on looking at a similar solution for doing the background colors for my text areas instead of using EditText

The reason I was using ClearScreen() was that in my app, I clear the screen in response to an external command to clear the screen and set the color, so I was needing the clear anyway and originally thought the color would be applied only by the ClearScreen() given the function is called SetClearColor() ! The documentation said I needed to call swap() after the clear. In order to try to get it to work I threw everything at it!

I tried the update() and Render() functions separately on the color buttons so each button had its own 'update' call but admittedly all are followed by a sync() pretty soon anyway.

I don't actually know what the Studio version is or what it does yet, I just started a week ago with Classic. When I initially reached out to tech support they suggested I try
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 20:06 Edited at: 2nd Nov 2021 20:33
I remembered to go and check if EnableClearColor() might help...

Turns out it has been deprecated... On Android is generates a run time error:

Quote: "EnableClearColor() has been removed from AppGameKit and no longer does anything, it should be removed from your code."


Well, in fact it does do something, it creates an error message!
Dale Schultz
1
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 2nd Nov 2021 20:32 Edited at: 2nd Nov 2021 20:52
I have tested the sprite approach and am happy to report that it does provide a working workaround!

Thanks

Edit: I did have to make the sprite a big larger than the screen as it seems some of the rounded corners of the screen give some 'extra' space and they get covered now too!
Virtual Nomad
Moderator
17
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 2nd Nov 2021 21:59
Quote: "it does provide a working workaround"

good to hear. forward!
finchalex
1
Years of Service
User Offline
Joined: 26th Jan 2022
Location:
Posted: 26th Jan 2022 19:30
I'll make a minimal sample project to demonstrate it and also try your exact code snippet.

What I did was place an additional SetClearColor( 207,207,207 ) within the loop that calls sync() and it still did not fix it.

I'll also try and look for a workaround using GetResumed. I did look at EnableClearColor() but did not try forcing that to true explicitly.

My screen is made up with numerous EditText boxes that are inactive.

The colors and text that displays is sent over a TCPIP connection.

All the background areas that are not blue is the screen background that should be blue.

Login to post a reply

Server time is: 2023-03-24 18:47:02
Your offset time is: 2023-03-24 18:47:02