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 / T2 Windows: Screen Resolution with black border

Author
Message
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 6th Nov 2012 08:12
Before messing my way through core.cpp is there a quick and easy way to open agk on a larger screen resolution on Windows without stretching, but showing a black border for a Full screen display (not windowed mode)?
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 6th Nov 2012 16:14
In Windows, no.

In fact, you will need to make a similar change in all the platform specific core.<x> files to make sure that your app knows the resolution size of the target screen.

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 6th Nov 2012 21:36
mmmmmm not good news for me
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 6th Nov 2012 22:30
I am assuming you are working in Tier 2.

What is your difficulty?

As for full screen, I can get my apps to go full screen without stretching. And it shows black bars on the sides or top/bottom to fill it, depending on which dimension doesn't work when the other fills the space. It keeps the same ratio for the basic app as originally set.

Cheers,
Ancient Lady
AGK Community Tester
Cliff Mellangard 3DEGS
Developer
18
Years of Service
User Offline
Joined: 20th Feb 2006
Location: Sweden
Posted: 6th Nov 2012 22:44 Edited at: 6th Nov 2012 22:46
This maybe stupid?

Why do you want the black borders?

Why dont you use overdraw?
Now with the new command sets in the latest beta can you get screen cordinates at the edges even with overdraw.

I added these to my on screen buttons right now and they work great!

-Added GetScreenBoundsLeft returns the edge of the screen in you chosen virtual resolution, this takes black borders into account to the left of the screen my be a negative value in your current virtual resolution
-Added GetScreenBoundsRight returns the edge of the screen taking black borders into account

Android 2.3 , ZTE Skate , 480x800 , 800 mhz , Samsung Galaxy Y , 240x320 , 832 mhz , Sony ericson arc 480x854 , 1 ghz
Android 4.0 , Dmtech 3g 9738B , 1024x768 , 9.7 inches , 1.2 ghz
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Nov 2012 00:25
Ancient lady, yes I am using T2 windows, but i cannot get AppGameKit to open in fullscreen mode, WITHOUT stretching and with black borders around.

I can get fullscreen mode with stretching, and it's causing a very bad pixellation effect, that's why I need the black borders.
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 7th Nov 2012 15:23
Are you using virtual resolution or percentage for display?

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Nov 2012 16:29 Edited at: 7th Nov 2012 16:30
virtual res

and you?

the artwork is a fixed res, so stretching really destroys the quality. i don't mind resizing down, but not expanding
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 7th Nov 2012 17:37
I'm using virtual resolution with fixed resolution artwork as well.

Will you show me the code where you are setting up your display resolution?

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Nov 2012 19:06
agk::SetVirtualResolution (1024, 768);
agk::SetResolutionMode (1);
agk::SetOrientationAllowed (0, 0, 1, 1);
agk::SetSyncRate(60,0);

Don't want it to stretch.
Just open a 1024x768 window in the middle of the screen with black borders around all 4 edges.

I think the trick is to edit core.cpp not the main agk code
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 7th Nov 2012 19:22
You can drop the SetResolution command. That gets done by core stuff automagically and has no affect whatsoever on anything other than iOS devices.

Quote: "
Just open a 1024x768 window in the middle of the screen with black borders around all 4 edges."

I misunderstood. I did not realize that you did not want the the app to change size at all. I can't help you with this, not having tried it myself.

I haven't looked at the details in the core.cpp file to see where you might make that change. But, if you found someplace that you think would do the trick, it may be your only option. And I'd be curious to look at that portion of the code, if you've found it.

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Nov 2012 21:28
yes that's what i need

i need my opengl square to stay 1024x768 in the middle of the screen, so that graphics are not stretched and expanded, giving that ugly pixel look.

will post back if i find a solution (i have to find one for sure)
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 7th Nov 2012 22:48
bj - I can almost certainly do this in the Pascal version for Windows only. But let's say we want this to run on my netbook, which is 1024x600???

Presumably what we really want is a bit like scaling images to fit into the current screen resolution: we ask "What is the best rectangle (keeping aspect ratio) that will fit into the client screen rectangle?"

It seems to me that trying to do something that will work at phone resolutions and say a 1920x1080 monitor really does require some different resources. Is this the dilemma we all face?

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Nov 2012 22:51
Jim, scaling down is ok, scaling up NO!

Problem is only Windows related.

Unfortunately I am using AppGameKit C++ not Pascal.

If I don't find a solution until Sunday I'm in big trouble!!!!
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 7th Nov 2012 23:02
Why do you need it to work full screen? Might it not be easier trying to figure out how to disable the full screen mode?

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Nov 2012 23:47
unfortunately it has to be full screen
JimHawkins
15
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Nov 2012 00:29
bj - I understand. Pascal can always be reflected back to C++ when we know what we're doing.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
fog
21
Years of Service
User Offline
Joined: 5th Oct 2003
Location: Newcastle, England
Posted: 8th Nov 2012 13:16
I think you could fudge this although there's no doubt a much easier way!

I haven't AppGameKit here to test with so commands might not be 100% right but here goes...

- In core.cpp there's a CreateWin32Window() method which you can modify to create a fullscreen window that matches the current desktop res.

IIRC there is already a Rectangle variable in there that stores the desktop res so you can simply use those as input parameters in the later CreateWindow() call that actually creates the window.

It's pretty straight forward. It can't be too tricky if I can understand it

- Your virtual res needs to match this so we get no scaling at all.

Assuming your intended game res is smaller than your desktop res (which I believe is your problem) then set your virtual res to match the device width (obv agk::SetVirtualResolution( agk::GetDeviceWidth(), agk::GetDeviceHeigth() ). I think you still need this otherwise AppGameKit defaults to the percentage system(?) Like I say, I can't test that now.

- Your game should now display unscaled.

- The game screen will be positioned top-left so you will need to add a camera offset to centralise it.

offsetX = ( agk::GetDeviceWidth()- yourGameWidth )/2;
offsetY = ( agk::GetDeviceHeigth()- yourGameHeight )/2;

agk::SetCameraPosition( -offsetX , -offsetY )

- If you don't want anything to appear that is outside of your intended game screen then use agk::SetScissor(offsetX , offsetY, offsetX + yourGameWidth, offsetY + yourGameHeight ) to effectively create the black borders.

- If you're already panning the camera then you will need to adjust it's position and SetScissor() accordingly.

Like I say, a completely untested theory and it might not be good for performance, but it should/might work.

If you're still struggling I'll have a look tonight if I find time.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 8th Nov 2012 15:32
Quote: "- Your game should now display unscaled. "

I made this same misunderstanding of his intent. He doesn't want the size of the app to scale at all. The app needs to always be exactly the same size, centered in a big black field.

Cheers,
Ancient Lady
AGK Community Tester
fog
21
Years of Service
User Offline
Joined: 5th Oct 2003
Location: Newcastle, England
Posted: 8th Nov 2012 15:59
Quote: "He doesn't want the size of the app to scale at all."

Which is why I said "Your game should now display unscaled." in the very bit you quoted.

Quote: "The app needs to always be exactly the same size, centered in a big black field."

Which is what I thought he wanted and exactly what I was, hopefully, trying to show.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 8th Nov 2012 16:16
Sorry, I didn't read it closely enough. My bad.

Cheers,
Ancient Lady
AGK Community Tester
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 8th Nov 2012 16:25
Fog very interesting theory which i will definitely test out tonight.

I did not know about this command: agk::SetCameraPosition()
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 9th Nov 2012 09:10
I found out that the ugly pixelling effect when stretching was caused by the min & max mag filters being switched off.

i had to switch these off because AppGameKit adds some ugly black line borders to SOME sprites when they are resized.

So now artworks looks very smooth when stretched, but some sprites have black borders. The thing that annoys me is that this happens to SOME of the sprites and not all. Will have to add some extra transparent lines to these sprites with the hope that the black lines disappear!!!

But I still plan to test out the suggestion from Fog.
fog
21
Years of Service
User Offline
Joined: 5th Oct 2003
Location: Newcastle, England
Posted: 9th Nov 2012 09:34
Quote: "So now artworks looks very smooth when stretched, but some sprites have black borders. The thing that annoys me is that this happens to SOME of the sprites and not all. Will have to add some extra transparent lines to these sprites with the hope that the black lines disappear!!!"

When I was using XNA the advice was to always have a blank row of pixels around each sprite in your spritesheets. It's a habit I've got into now and I've never had any problems with borders on sprites in AppGameKit regardless of min & max mag filter settings.

I use my own animation system and not the built in solution, but I doubt that's a factor.

bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 9th Nov 2012 22:27
Fog, I have changed the size of some of the graphic files to be 128x64 instead of 120x60 and sometimes the black lines disappear! but it does not happen for every sprite.

this only happens when the screen is stretched. when the app resolution & the default desktop resolution are the same, and no stretching happens, all is ok
fog
21
Years of Service
User Offline
Joined: 5th Oct 2003
Location: Newcastle, England
Posted: 10th Nov 2012 10:09
Are you telling your sprites to use the whole of this new image size or just the original portion?

In my system the blank 1 pixel border is outside of the image I use on my sprites. (ie. In your case just use the 120x60 section of your image and not the resized 128x64 one)

In my animation system I just offset the spritesheet UV's but I assume it's easy enough in the AppGameKit animation system too?

Ian Rees
AGK Developer
12
Years of Service
User Offline
Joined: 3rd May 2012
Location: Wales, UK
Posted: 10th Nov 2012 14:17
I had similar issues with my sprites which were resolved with SetSpriteUVBorder:

SetSpriteUVBorder(mySprite, 0.5)

E

http://www.superiorinteractive.com/galaforceworlds
fog
21
Years of Service
User Offline
Joined: 5th Oct 2003
Location: Newcastle, England
Posted: 10th Nov 2012 14:44
Quote: "I had similar issues with my sprites which were resolved with SetSpriteUVBorder:

SetSpriteUVBorder(mySprite, 0.5)"

That might work although according to the help files that could result in part of the sprite not being drawn at all.

Quote: "...however this means that the outer most pixels of the sprite's image may not show. "


Mind the help for that command is a confusing mess of contradictions so who knows.

bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 10th Nov 2012 16:34
having to do SetSpriteUVBorder for every sprite is a bit too much, i have hundreds of them!
fog
21
Years of Service
User Offline
Joined: 5th Oct 2003
Location: Newcastle, England
Posted: 10th Nov 2012 19:03
Quote: "having to do SetSpriteUVBorder for every sprite is a bit too much, i have hundreds of them!"

Don't you have the AppGameKit sprite creation commands wrapped already? You really should IMHO as this sort of change is then very easy to do (it's one line) and makes it so much easier to use your C++ code with another library in the future if you need to.

Ian Rees
AGK Developer
12
Years of Service
User Offline
Joined: 3rd May 2012
Location: Wales, UK
Posted: 10th Nov 2012 21:09
Quote: "having to do SetSpriteUVBorder for every sprite is a bit too much, i have hundreds of them!"


Yeah - not great. I only had to do it for a handful of sprites - but if I needed to I would have added SetSpriteUVBorder to them all.

Are you using 1076? Only a few of my sprites were affected - are you saying that "hundreds" of your sprites are affected?

E

http://www.superiorinteractive.com/galaforceworlds
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 10th Nov 2012 21:35
yes i am using 1076.

the problem is that different screen resolutions produce different artefacts, so the only 100% reliable way is to apply the UBborder command to all sprites.

i have also noticed that when the game is scaled down, using the UVborder command with 0.5 cuts off 1 pixel from all around
Ian Rees
AGK Developer
12
Years of Service
User Offline
Joined: 3rd May 2012
Location: Wales, UK
Posted: 10th Nov 2012 21:41
Quote: "i have also noticed that when the game is scaled down, using the UVborder command with 0.5 cuts off 1 pixel from all around "


Yes, it does. I had to increase some sprites to have an unused border. If you have to do this for all your sprites it could be time consuming.

I hope you get this sorted. If you come up with an alternative solution I'd be interested in knowing...

Good luck.

E

http://www.superiorinteractive.com/galaforceworlds
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 10th Nov 2012 23:05
the "best" solutions seems to be to use NO command at all, and have all artwork in 64x64 or 128x64 or power of 2 size.

i will try to put everything in spritesheets as this will make things easier, and hopefully the problem will go away.

Login to post a reply

Server time is: 2024-11-24 01:45:48
Your offset time is: 2024-11-24 01:45:48