I just compiled my app to macosx intel and universal.
My friends system is 10.6.8, intel.
While things seem to be working, control and sound, I get no image but the smallfont in full screen.
It works fine on PC and used to work fine on MACOSX back o GLBv11.
So I take something changed. Anyone has a clue if something changed? Are you guys having trouble on Macosx?
I tried to debugg it this morning but it is hard to do it by google hangout as this friend of mine lives in another town and I have no mac anymore.
The only thing that changed on my code from when it used to work to now, is that I´m using a virtual screen and the command USESCREEN -1, could this be broken?
Paths are all fine as sound loads. I´m also first creating screen and then loading assets, no trouble here.
I´m moving the file zipped, like I used to do too.
Any hints? (I miss my hackintosh :( )
If you think it may be USESCREEN etc, then generate a small test program without it (and maybe a 2nd one with it?) and see what happens?
recently MrPlow vikini game did worked quite nice on my Mac OSX with anything worked correctly. Its used a windowered mode game. Im do have no idea which graphics/alpha setting MrPlow using, but its was changed in v12 as im remember. So this can been a issue as well.
For Greedy Mouse, the only issue im had was and is still the vSync issue, which look ungly in that game (even im try to set it by inline code). This game do not uses any virtual screen modes at all.
Im do think the main issue is fullscreen have never been worked due sdl limit. So dont try to do that, but instead uses a big windowered mode, but could also been due the default alpha setting its is changed.
But its can been something happens with CREATESCREEN, but im have not used it here, and im dont know if MrPlows game used that.
Now it is really strange, I made a new project and it worked.
I changed the test project to fit the structure from my game and copied a few assets and it worked too.
I made it quite similar to what is happening on my game and it all works (the font does not display though, strange?)
Now I got my game´s project and made a new project with it and it still dosen´t work.
Game works on the background, sounds are playing and control is working, but all I get is the FONT2.png displayed on screen.
There is no place in my game where that file is displayed so I´m a bit lost on what the heck is happening.
I´m appending a mac picture here.
I´m also appending the MAC test project I did. The project works fine but the font does not display as on PC, it is the same file that on my game gets like the screen shot.
I´m quite lost here, I don´t think I will be able to find the error more then I tried today relying on a non-local mac.
If no one ever saw such a thing, I may need to have a mac by my side to check step by step.
So maybe a virtual machine to run a mac could help here. Really sucks.
EDIT: notice here on test project, I´m loading a font and a bitmap and using virtual screen, it works.
hmmm, I intended most of my subroutines leaving only the most important for a single screen display.
I intended both LOADFONTS from my code and guess what.
The hanging image on screen is now the next image loaded.
So it seems my code is showing on screen the very first image loaded, which is strange as in my test project that does not happen.
I thought it could be the usescreen -1, but how come it dosen´t happen on the test project?
Either way, I can stripe down my project to a minimun to check what is happening or when it comes to normal.
im have checked your project.
Its seen OSX have quite limited virtual screen support. Print does not working on other than USESCREEN -1. Its seen im did the correct choice to dropping using virtual screens completly (im have many issues as well, so its was not very useable for me at all, here its was multiply issues with alpha), but instead draw sprites directly to the backbuffer. This is also much faster too (twice really).
But im have no idea about the vikini game, since its worked without a issue. he have property avoid used the problem command too and used his own font system, which is quite very easy to made.
So this is a bug, but its property a SDL issue which needs a upgrade. Im see why its happens, its could been the small font image? but its a strange one.
If you want im can send you set of functios im used for scaling as well the font system to you per email.
PS. Karma Miwa run nicely on my Mac, but with few issues (vsync is missing, and music volume commands not working too).
PPS. If you used that kind of hardcodning, you property have quite issues too. Again im have changed the project a bit, im can send that to you too.
Thanks for the offer Space, I will have to think about this all, a mac release is important.
I have extendedly tested the program today(ooh what a waaaste :'( ) to figure out what is the problem.
I did not have problems with font loading neither virtual screens on mac prior to v12 of GLB.
It seems as I loadsprite a bmp image it works fine, as soon as I load 2 of them, or animsprite, I get the bugged display showing the very first bmp loaded in a wrong set.
Font is not loading at all as a font, but gets error displayed so I take GLB read it at least.
Can someone confirm? I´m appending the project here, if it holds true, might as well get it to the bug list.
confirmed. Virtual Screens is not supported very well in Glbasic v12 for Mac OSX. But its does works fine as long you not using it. Im happy im newer used virtual screens at all (im dropped its, due speed and alpha multiply issues).
Also that way you uses hard coded on Android, dont works at all. You face issues, due toolbars, not returned to GETSCREENSIZE(), and controls fails to shown correctly or at all. Im do cant see a problem why you diddent have calculated tcx, tcxb and tcy based on the reported resolution for the controls? Its a quite very easy and have show a example a more correct way. Im do not sure what Andr does.
The globals issues you have is quite simple: Just move them out of the subs to the top of the gbas code, then its fix the warnings.
PS. email me, if something im need help you. You helped me, so now its mine time.
Thanks Space, I still have to finish the trailer and do a boost in marketing for Karma Miwa around here. :good:
I just took a couple weeks off into my game to at least advance some stuff. I will have to move again in a couple weeks, hopefully for a final target, and need something to cheer up. While android is doing ok, Mac is not, but I guess I can recall an older GLB version to cover that up as it was working fine before.
Even if I delay a release for android (and extra platforms) a bit further for the issues on screensize, I must/should have a working PC/MAC/LINUX to boot to fit the desktop stores.
I like virtual screens and think they should be working and possibly better. I guess my reason is that it was the only way I found in this game to keep the pixels the way I wanted, so I´m not sure to change it at this time, probably next project I will look into a different display solution.
Yep the variable errors gets fixed bringing all declarations back into the main code, no problems with that.
Back on the subject,
Are you sure the virtual screen is the problem and not the loading assets commands? Do they all work fine without the virtual screen?
If so, then I should do an entry on the bug side of the forum.
I can´t make sure of it right now as my friend with a mac is offline (after I toasted his brain to test 200 files today...) :whistle:
yes im tested it. When im changed to uses USESCREEN -1 without using virtual screen, both images did shown correctly as well the FONT. So they got loaded, but screwed up when drawing to the virtual screen. But on the backbuffer, its worked fine on my Mac.
personly im did never liked it anyway and avoids to uses it. This was due im did have many alpha multiply issues as well lost about half of the framerate. drawing from birtual screen can been slow on some devices.
But even not using virtual screen, you can still have perfectly lowres pixel art graphics. This is depend how scaling using, which here all could have been performed by a external PaintImage function to do all calculations for you before draw a image (this is what im did for my games, internal its was a fixed resolution too). That include placements and aligements of pixels. The ingame engine does not need changes throught here.
The only main issue after the change is got controls working again with precalcuated placement. Sady my devices wont run your game, due hard coded resolutions (two of my devices have toolbars, the last one is a 480x320 screen, but not using a toolbar).
email me for eventuely help.
Ok, will move the issue to the bug forum side then.
I will add resolutions for the menu bar thing, I just need figure what are their usual sizes and add it up (I hope it is not like 50 different menu bars all around), probably needs some testing with a device like that too, so I might ask you to give a go later.
There is an LG android phone here that is 320x240, it runs the game fine but around 40-50 fps. So slow older phones are not going to handle the 60fps I want, but I really don´t wanna bother old devices. I could change it to 30fps limit though, but this is another set of problem, better focus on the mac part here.
You should not use = for resolution checks, it's bad, but instead just uses nearest hard code resolution (using < or >) as I'm wrote there, and then center the screen by using VIEWPORT command (it's a quite strong command, it's move hotspot too). This is easist fix for you by now. But this is off typic talk, we should talk in your other thread. Sorry about it.
Please move it's to bug section.
If you can avoid virtual screen, then it's would run on Mac OSX too. It's a virtual screen issue.
Space, back on my first project example, I loaded a font and a bmp with loadsprite.
Things worked with the virtual screen.
On my latest project, any other bmp loaded with loadsprite broke it, maybe this helps point out the trouble?
I´m not yet sure the problem is related to usescreen, but maybe there is something wrong with the load part?
its just funny its worked here as long im diddent uses virtual screen. Im do think you should uses your own font rutine, since the default one is mostly used for default thing anyway. Its far quite limited.
You should do example, so Gernot can look what its happens. They should look same on Mac as on PC.
Also VSYNC and Music Volume commands also not working on Mac OSx too. Im do more thinks its really a USESCREEN issue. Try to draw them for fun to the backbuffer and see what it happens with USESCREEN -1.
Here its worked without issue. This can been why both MrPlow game and both my games working fine (dispite ugly vsync issues for my games, its a different issue here). But its still a confirmed bug and a great example to show the bug.
Don´t worry about the font, that one is only used to display debug info on screen during game, it is not actually IN the game.
I can´t do much testing here as I have no MAC, I will probably get a hackintosh or virtual running later this year to have something to test.
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... ;)
you cannot use VIEWPORT, because im have just discovery a bug. While DRAWRECT works correctly to VIEWPORT, MOUSESTATE does not:
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.
Might be worth trying MOUSESTATE use come after SHOWSCREEN
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.
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.
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.