Little autoscaling system with a virtual Image (suitable for Android).

[fuzzy70]

Linux can, quite frankly, be a nightmare to deal with or everything works without problems. While I am very familiar with using Linux including building/compiling/installing apps etc from source they vary a lot between distro's. I never really dug deeper into some aspects of it like sound or graphics but just simply followed the dependencies of whatever I was installing.

Gfx drivers where a cause of numerous headaches as the "Official" binaries from the likes of Nvidia or Ati/AMD where not guaranteed to work on all distro's resulting in having to use alternate ones which lacked features like hardware 3D acceleration or something else. Same went for sound in that you had OSS/ESS/Pulse Audio plus others & I never really got to the bottom of what the differences where other than some programs used one over the other. I have even come across distro's where the supplied games where silent even though the had sound options & had to install a different sound system to the default one to make audio work.

Drivers have pretty much always an issue with Linux due to manufacturers of hardware refusing to open source their ones & making binary only versions for whatever distro they see fit to support, which is no fault of Linux itself.

So many options has its plus points in that you can tailor the system to your needs, but the offshoot of that is not everything you want will work without some extras or tweaking.

Lee

[erico]

I see, but you have the likes of humble bundle, which needs pc mac linux support games the least.
They probably don´t have to bother the minimum details of each disto?

But somehow it has to work with at least one, or the more popular or easier ones.
So I was wondering, UBUNTU seems to be the more popular one, at least propaganda wise.
I have to set up something that makes sure at least a base of linux system works with the output of GLB.

[fuzzy70]

I have purchased quite a few Humble Bundle games, some of which there are no Linux versions but they are in the main games or bundles that where Windows specific. I just had a look at my account & some require MOJO whatever that is, some are as DEB packages, some are .BIN & others are .tar.gz (whether they need to be compiled from source I'm not sure).

I have to be honest & say that games where not really my thing on Linux other than some of the Gnome desktop games like "Robots" or puzzle/card games. I did have issues with GLB programs I wrote in Linux, none of them using sound but just graphics in that they would just flash a window then close or output was not the same as it was in Windows. Again that was down to different distro's, worked fine on some & not on others even with installing any required libraries.

Unfortunately I have not had Linux installed for a year or 2 but when I last had it I tried Fedora, Open SUSE, & Xubuntu, I was never a fan of regular Ubuntu with Unity & the lightweight Xubuntu gave me the same software but without the extra bloat & resource hogging of the regular version. I think Fedora gave me the most issues with respect to getting a fully functional gfx driver installed as Nvidia didn't provide one for it at that time, Open SUSE had some issues that I do not recall at the moment & Xubuntu I was unable to use my wireless card without a lot of messing about when I installed it even though it worked perfectly if I ran it from the LiveCD.

All in all a lot of fun & games, whereas my previous pc I had very minor or no hassles at all so it is pretty much the luck of the draw. I will return to Linux at some point but it's not high on my list of to-do's 

Lee

[erico]

Hmmm...I´m trying to implement this function on the avocado game and am failing miserably...
It keeps blank, I made a few alterations with no success yet.

[Ian Price]

Here's a tip erico.

Create a virtual screen the size of the caanoo screen. Use that screen to draw everything to. Then use the normal screen and either use POLYVECTOR to scale or STRETCHSPRITE or ZOOMSPRITE to display the image.

Here's a simple demo to show how to scale (even 10 all round). To scale to rectangular screens you might need to use SCALE_X and SCALE_Y variables.

Code: GLBasic [Select]

SETSCREEN 640,640,0

CREATESCREEN 1,999,64,64

GLOBAL scale%=10 // Scales the virtual screen by factor of 10

 
 WHILE TRUE

  // Use virtual screen to draw on
  USESCREEN 1

  // Draw rects randomly by pressing SPACE
  IF KEY(57)
   FOR n=0 TO 300
    DRAWRECT RND(64),RND(64),RND(16),RND(16),RGB(RND(255),RND(255),RND(255))
   NEXT
  ENDIF

  PRINT "PRESS",10,10
  PRINT "SPACE",10,20

  // Draw the scale virtual screen on the actual screen
  scale_screen()
 
  // Draw original screen sprite, so you can see the scaling
  DRAWSPRITE 999,0,0
 
  SHOWSCREEN
 
 WEND
 


// Scale virtual screen scene
FUNCTION scale_screen:

 USESCREEN -1

 SMOOTHSHADING FALSE

 // Render whole scene in scaled screen
 STARTPOLY 999
  POLYVECTOR 64*scale,0,64,0
  POLYVECTOR 0,0,0,0
  POLYVECTOR 0,64*scale,0,64
  POLYVECTOR 64*scale,64*scale,64,64
 ENDPOLY

ENDFUNCTION
 

Hope that helps make it a bit clearer.


[EDIT] Or you can use the PRESCALER function from the latest versions of GLB. Call it at the start of the code and then just draw everything as normal. Supposedly. I've not used it and I don't know what impact it has on gamespeed. USESCREEN can also affect FPS, so be forewarned.

[erico]

Thanks Ian, that is what I´m doing, but I have fixed android resolution detection, while this more advanced version SF did can handle infinite android resolutions+calculate the touch zone. I understand the concept as you said but not the math in SF´s code and so I can´t fix it.
I was wondering if this function was tested before and the errors are on my side only.

[Ian Price]

It's easy to set up autoscaling based on resolution and finding the touchscreen positions. Simply divide the actual resolution (x and y) by the required resolution eg - if the actual X resolution is 1020 and your screen is set up for 320: 1020/320=3.19 so every pixel the mouse moves to cover a 320 res screen should move 3.19 pixels on the larger res screen. Use something like this -

Code: GLBasic [Select]

LOCAL mx%, my%, b1%, b2%
LOCAL  cx#, cy#

MOUSESTATE mx, my, b1, b2

cx=mx*3.19
 

Obviously you can automate the actual value too

Code: GLBasic [Select]

GLOBAL w%, h%
GLOBAL screen_x=%320; screen_y%=240
GLOBAL res_x#, res_y#

GLOBAL mx%, my%, b1%, b2%, cx%,cy%

GETDESKTOPSIZE w,h

res_x=w/screen_x
res_y=h/screen_y


WHILE TRUE

MOUSESTATE mx, my, b1, b2

cx=mx*res_x
cy=my*res_y

SHOWSCREEN

WEND

 

Or something along those lines (BTW not tested in GLB).

This should give you a fairly accurate mouseposition on the screen.

[erico]

That is what SF´s function is supposed to do. Strange is that I just tested it alone and it works.
So it is probably that I screwed something while adding it to the game.

I will try again.

If I can´t make it happen, then I will have to write one and I will follow your tips

[erico]

Fixed.

It was a couple variables that got declared on the wrong order on my code, now it is all fine, works like a charm.
I´d just have to cut off the broken resolutions now.

Really great code.