Author Topic: OSX compiling problems GLBv12  (Read 6367 times)

Offline erico

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 4448
    • View Profile
    • FUED
Re: OSX compiling problems GLBv12
« Reply #15 on: 2014-May-30 »
Here I was wondering, would a VIEWPORT solution helps me on this issue? (ye, it is also related to android :D)
I have no experience with it, I´d have to look into it.

Let me recapitulate:
.I have a 428x240 virtual screen set
.All game stuff happens there and movements are also hardcoded into that resolution.
.Finally I set that virtual screen to a sprite and zoomsprite it to a pre-set final resolution.

I was wondering if:
.Create the final resolution first.
.Run all my game stuff, as hardcoded, will take the 428x240 top left part of the screen.
.Use viewport to focus that 428x240 into full window.

Does it work out like that? Have you guys any experience with it?
It might solve my Mac issues and also help the Android side of things... ;)
 

Offline spacefractal

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 4020
    • View Profile
    • Space Fractal
Re: OSX compiling problems GLBv12
« Reply #16 on: 2014-May-30 »
you cannot use VIEWPORT, because im have just discovery a bug. While DRAWRECT works correctly to VIEWPORT, MOUSESTATE does not:
Code: (glbasic) [Select]
GLOBAL mx, my, b1, b2
SETSCREEN 800, 600, 0
SYSTEMPOINTER TRUE
REPEAT
VIEWPORT 80, 80, 640, 480
DRAWRECT 0, 0, 640, 480, RGB(0, 0, 250)
MOUSESTATE mx, my, b1, b2
SHOWSCREEN
LOCAL st$=mx+" "+my+" \n"
DEBUG st$
UNTIL KEY(0)=1

So im was not aware about the issue, so dont think about VIEWPORT, but instead using PaintImage() function. VIEWPORT is great for clipping graphics, like on a mirror.

PS. You could on Mac/PC remove the virtual screen and just double up all your graphics assests and then use the windowed mode. Im do hope this bug soon got fixed throught.

« Last Edit: 2014-May-30 by spacefractal »
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation and The beagle Jam.

MrTAToad

  • Guest
Re: OSX compiling problems GLBv12
« Reply #17 on: 2014-May-30 »
Might be worth trying MOUSESTATE use come after SHOWSCREEN

Offline erico

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 4448
    • View Profile
    • FUED
Re: OSX compiling problems GLBv12
« Reply #18 on: 2014-May-30 »
hmm, but on MAC I need no mousestate, just keyboard and joystick will do.
On android, I can use my sloppy routine to check mousestate based on device resolution.

So it is a possible idea, I will save it to give a try.

Offline kanonet

  • Administrator
  • Prof. Inline
  • *******
  • Posts: 1137
    • View Profile
    • My GLBasic code archiv
Re: OSX compiling problems GLBv12
« Reply #19 on: 2014-May-31 »
I think MOSESTATE has nothing to do with VIEWPORT, its intended that it does not get affected. Remember that a viewport is only a generic output "window" in your program window, you can generate several ones of them, so at which one should MOUSESTATE work, e.g. if you make a 4 screen split screen game? You use it only to modify your single window, but thats not the only purpose. Im sure MOUSESTATE is guaranteed to be global to the whole screen, not only the viewport.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Offline spacefractal

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 4020
    • View Profile
    • Space Fractal
Re: OSX compiling problems GLBv12
« Reply #20 on: 2014-May-31 »
you could just reset viewport again. There is acutelly no reason to fix it either. its easy to find the top/left hotspot anyway: You have allready set its values.
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation and The beagle Jam.