I posted this elsewhere but thought here would be better.
This code on the iPhone keeps building up used memory until it eventually crashes:-
ttime=GETTIMERALL()
ttotal=0
tsprite=GENSPRITE()
WHILE 1=1
IF GETTIMERALL()-ttime>100
LOADSPRITE "Media/1-1.png",tsprite
INC ttotal
ttime=GETTIMERALL()
ENDIF
PRINT ttotal,0,0,10
SHOWSCREEN
WEND
If I use a loadsprite "",tsprite directly after the loadsprite command it makes no difference. From the graph in XCode you can see it gives back a little memory when loading the sprite again (seen by spikes in graph), but nowhere near enough.
Cheers
[attachment deleted by admin]
Can you try to find out what functions allocate but don't release.
Try the code on windows and it will not leak, right?
I believe it's the loadsprite command. You can load the same sprite file over the top of the same sprite bank (as example shows) and the allocated memory on an iDevice just keeps building. The graph shows a small amount is released every time but only a tiny amount. After my memory is used up (just after 256mb) then it crashes as can be seen in the screenshot.
My PC is fine in the task manager, but as someone else mentioned earlier this doesn't show memory used by the video card, whereas the iPhone has it all in one memory allocation.
I removed the printing on the screen incase fonts were causing the leak, and tried a loadsprite "",tsprite after every loadsprite to see if that cleared memory, to no effect.
The only other thing I just thought of is that the image I have loading comes from a shoebox on the iPhone. Doubt it makes a difference, but you never know.
If I get a chance tonight I will modify to just have a while/wend with a loadsprite command inside it and nothing else. So is the same idea with it loading the same image into the same bank, but with nothing else at all. I'll also try without a shoebox.
Cheers
Yes, try it without shoebox as well, just in case.
Oh! Shoebox might ring a bell!!
Can you please try without? I tries with the MESA OpenGL wrapper on Windows and still no leak.
In that program, before you delete / overwrite the texture, please try: X_SETTEXTURE -1, -1, 0
It might be that GLBasic can't delete a texture if it's still bound. That would explain it.
Ok, will try a few things tonight. Didn't get the chance yesterday.
Also on the question of sprites, is there a way to load them at a certain percentage size? I know you can resize when you draw them, but I was thinking of when everything is loaded at different resolutions to save memory and speed (rather than loading everything full size then resizing when drawing the sprite).
Essentially I was thinking of a routine that would take the resolution (specifically thinking of iOS here) and load all the sprites and save them back as the correct size for the resolution. So if you have an image of 500x500 and that's for the max res screen of 640x960 (iPhone 4), then getting a screen res of 640x960 would keep the image the same size, but a screen res of 320x480 (iPhone <4) would paste it to the screen but resized at 50% ratio, then grab it again as the sprite to use (or even save as the proper sprite). So would end up with a 250x250 sprite for future use.
The main problem I see with this idea is partially transparent sprites (is it alphablended sprites?). By making the backscreen pink then pasting a sprite should keep the transparency when I re-grab it. But does GLB support partially transparent sprites? If so then I'm stuck there. It would overall be much nicer if we could load a sprite at a set percentage. That way a pre iPhone 4 would load the sprite at 50% (in both X and Y) size, resulting in using up 25% of the memory it should take up, plus obviously it will be faster than the zoom sprite commands. Or to have a save sprite command that can save the sprite at a set percentage, keeping all transparency (including partial transparency) settings. That one would be quite good actually as we can then save new smaller sprites and the loading should be faster in the future as it wouldn't have to load a big sprite and then then resize it into memory. What do you think?
Cheers
I had this solution on the iphone:
media/1024
media/960
media/480
in the program, you check the screen resolution and setmediadir ("media/"+resolution)
Also, notice you have to define "pixel size"
480=1px
960=2px
1024=2.13px
and every sprite movement is *PIXEL so they always move at the same speed in all resolutions.
But if you are thinking in porting your programs in the future for other devices (android can had tons of resolutions) I use this pixel size table:
// MODO 1=320x240 (1x) 2=480x320 (IPhone 1.5x) 3=640x400 (2x) 4=960x640 (Iphone4 3x) 5=1024x768 (IPad 3.2x) 6=1280x1024 (4x)
GETSCREENSIZE xres,yres
IF yres>=320 AND xres>=240
modo=1;ratio=1
ENDIF
IF yres>=480 AND xres>=320
ratio=1.5;modo=2
ENDIF
IF yres>=640 AND xres>=400
ratio=2;modo=3
ENDIF
IF yres>=960 AND xres>=640
ratio=3;modo=4
ENDIF
IF yres>=1024 AND xres>=768
ratio=3.2;modo=5
ENDIF
IF yres>=1280 AND xres>=1024
modo=6;ratio=4
ENDIF
Yeah, I was going to do something similar, except use a calculated ratio on the final draw. So I would calculate all movements, for example, based on an iPhone 4 resolution, then when actually drawing the sprites to the screen I would then use the calculated ratio for the exact positioning. eg. we are working on a 640x960 grid, but my calculated ratio is 0.5 (probably best to do one for X and one for Y to be 100%) as the target resolution is 320x480. So I may store an objects location at 600x900, but because of the ratio then when it actually draws it to the screen it will be 300x450. Combined with a setup that recalculates all sprite file sizes to the correct resolution then should be stress free (ish). Just must remember to draw everything using the ratio. eg. drawsprite 10,x*r,y*r. Should work fine.
Still, would be nice to have one set of highest resoltion images then resize and reload based on targets resolution. Which is where my routine, or ideally a loadsprite/savesprite command with an optional percentage parameter would come in handy.
Cheers
Yes, this error is to do with Shoebox. I just tried a project from scratch and loaded in sprites from set media and it works just fine. This was with loading the same sprite file into the same sprite bank every 100 milliseconds. I didn't bother with using the clear sprite command. Memory is allocated and it goes up and down a bit but overall it stays at the same level. Delete the image and use a shoebox instead and the memory keeps getting used up.
Ah well, I was a bit off shoebox anyway because it doesn't work for Wav for me on iOS, plus I think I'm being a bit anal if I think it looks a bit amateur to see all you image files in an iPhone explorer. At the end of the day who does that really? Plus it's not as if I am doing amazing graphics or anything.
Any chance of that loadsprite/savesprite command that loads them in at a set percentage or pixel size (both for X and Y)?
Cheers
Quote from: Crivens on 2011-Mar-18
plus I think I'm being a bit anal if I think it looks a bit amateur to see all you image files in an iPhone explorer. At the end of the day who does that really?
Use to do it all the time on the amiga on games that was possible to do so.
I didn't quite bother if that was amateur, at the end of the day I was really happy to see the gfx sheets.
I consider that a FEATURE hehe
heck I even do it on MAME once in a while and I remember reassembling RENEGADES's grafics once...
Yeah, me too. But on the iPhone it's that one level up where you need to download an explorer app to see the files on your iPhone. Literally that leaves people like us not your average Joe. I can live with that until I reach graphics perfection (which will be a long time away...)
Cheers
Ah, so it is shoebox, eh ?
Quote from: Crivens on 2011-Mar-18
Yeah, me too. But on the iPhone it's that one level up where you need to download an explorer app to see the files on your iPhone. Literally that leaves people like us not your average Joe.
You can consider your graphics as free marketing tool.
<--- See my avatar. It's from Monkey Island 2. I like it so much that I'm advertising it with each post. :)
Somebody might use your graphics in their online profiles or whatever and essentially advertise your game.
Also, many games come with "Art of..." books and soundtrack CDs that are part of "limited editions". It's the most efficient counter-piracy method that has worked since forever.
If you have graphics that are somewhat worth looking at, consider actually publishing them separately, or even putting them on your website for free!
For me it wasn't really about letting people use my graphics or not. It was more about looking a bit naff and amateur hour when using an iPhone explorer to view all the files. I don't really see that for other apps. On the other hand, as said earlier, it isn't the end of the world as you would have to be a bit geeky (like us) to even think of doing such a thing anyway, and as far as I know it's not as if iTunes shows it easily.
Cheers
I am also in "resources in a showbox". Although on iphone it could not be a problem to have them in separate files in /media, in other plataforms it could not be a good idea.
Now you have to test it on Win & Mac at least :)
I would mostly agree, but it is a good point about users changing the look of your app easily. Infact without shoebox my app would be easy to add your own levels (could do simple validation i guess) as it's a little twist on the common slider puzzle. Nice easy one for a first app really.
Out of interest say I decide to abandon shoebox for an update and use individual files. How do I then remove the old shoebox? It is in the media directory which means it cannot be removed by my app. Would be great if the memory leak was fixed though...
Oh and just now my first app (Rotaslider) went onto the store! Whoop! Thanks to Gernot for this excellent language! Really quite chuffed now. :)
Cheers
don't forget to post it on the appropriate threads...we all would like to have a beek! =D
open gfx where levels can be made can be a "feature" for the more advanced user while you create a map editor or something like that, try the best to use what is available to your advantage!
good luck!
Will post on the app store thread soon.
Yeah I know what you mean, but with plans to use online high scores in the future i would rather not let them have that feature. Plus I wanted to have that feature properly in the future once a lib appears to access the iOS camera or photos. Heh, the amount of bugs that a client has wanted kept in as it works as a good "feature" is always funny to me over the years. I program travel reservation systems and it is always a weird thing that they use in a clever way to allow something else.
Cheers
RotaSlider=Bought =D
Good luck with it.
Ooh ta! Hope you like it! Hopefully Gernot can fix that memory leak for shoeboxes and I will do an update. Then I want to get Bluetooth working properly. It was 90% there but I wanted to get it on the store first.
Cheers
Gernot, do you think you will be looking to fix the iOS shoebox memory leak soon? If not then isn't the end of the world but I was hoping to keep it using it instead of allowing the images to be freely accessible. Isn't the best with my game where you can basically easily make your own level if you have access to the individual images (using iPhone explorer for example).
Out of interest if I abandon Shoebox then on the next update I include all the media rather than just the shoebox, then the memory leak should be fixed, but what happens to the shoebox that got transferred to the iPhone with the first release? It can't be deleted by my app I take it, so will I just have to leave it there?
Cheers
I "think" the update will wipe the old program, leaving only the documents directory and write the new version.
Can you check with the task manager if the memory rises on win32? Here it didn't, which makes be believe there's something seriously bronken with my iPhone memory management.
But this would be the old shoebox not the actual program. Or are you saying the media is erased and redelivered each update so if removed the shoebox for the update and just used media then the shoebox would bs removed from the phone and replaced with the media?
Memory management is fine on my pc but then I don't have a graphics card that allows me to view the amount of memory that the video card is using up. I think so far the iPhone memory management is fine with normal sprites but anything from the shoebox will not clear properly.
While I've got your attention then any chance of a change to loadsprite to load things in at a set pixel or percentage size (both x and y separate)? This way one sprite can be used for any resolution at a set ratio without impacting performance or memory like zoomsprite will. I posted some code to do it yourself but I would prefer it inbuilt as it doesn't support partially transparent sprites (alphablended is it?) plus it would be better loaded into memory directly.
Cheers
No video memory leaks. It's the shoebox data.
You can either stretch sprites yourself with LOADMEMSPRITE or LOADSPRITE, CREATESCREEN, STRETCHSPRITE commands.
Hmm. Then no, I don't believe my PC loses memory. It's what surprised me with the iPhone memory checks. I can check again tonight though.
I do it myself already with the routine I posted here. Basically loadsprite, along with stretchsprite and savesprite (so all the correct size to be loaded again in the future). But I wanted it to do it directly with the loadsprite or savesprite commands really. My main concern was the partially transparent stuff as I don't know how to preserve that information. Does GLB currently support that? So that you have different levels of transparency throughout the sprite. If not then my own routine will get me by.
Cheers
with LOADMEMSPRITE you have the alpha information in the pixels.
When you "draw" the sprite to an offscreen surface, draw with alphamode -1 to preserver the alpha bits.
Does it have the full alpha information for semi-transparency? If so then can you use it to load something in at a lower % size (or to save with full alpha information)? My main thought is if you have graphics that are retina sized, then you can load them into a non-retina iDevice at a set size (ratio worked out at X and Y from the intended resolution). This way you use less memory and it's got to be faster than using zoom/stretchsprite commands when you need them drawn. This would be far better than having specific retina/non-retina/ipad graphics and would easily work on other resolutions.
Cheers
Crivens, to incrementate a bit your paranoia, you can find any .ipa in my documents/my music/itunes/...idontremember, rename the ipa file to .zip and et voilá, here you have access to all ipa files without using any iphone file explorer...
:nana:
On my current app, I am making a shoebox per file, so I have a ton of files with the name "nnnnnn.sbx", and only one file inside the sbx, "page.png", as I have only 1 page (sprite) in memory at the same time. To load it, I use setshoebox pagenumber+".sbx","" / loadsprite 1,"page.png".
Will it have the same memory leak problem?
Heh, I'm not really bothered about people nicking the files (I nabbed most of it from Creative commons sites anyway), just looked a bit naff, and that I didn't want anyone to easily create their own levels. For the level thing any other apps I have planned it probably won't matter.
Yes I think it should have the same leak. When I tried the test the second time I used a new blank app that only had one media file in a shoebox. Repeating loading the same sprite from the shoebox into the same memory bank used up more and more memory (releasing only small amounts each time). I even tried loadsprite "",spritenumber to see if it would effect things and it didn't.
Cheers
Gernot, would it be possible to add memory commands, something like GETMEMFREE, GETTOTALMEM,GETMEMUSED etc. to establish if/when/how much memory is being used, rather than using external tools like Task Manager?
That could be quite cool. The Xcode memory analyser is pretty good but it would be nice to have something inside the app itself too
Cheers
I would have to count that and it would make the program run a lot slower then. I have no idea how to get the used memory for cross platforms otherwise.
Ok, so I tested the same project in Windows making sure that I only have the shoebox for media, and yes it totally memory leaks all over the place here too, but if I remove the shoebox and reintroduce my media it is stable and does not leak.
So it isn't just the iPhone. Hopefully this means it is a simple fix?
Cheers
please send me the project!
The project is a bit large so I've made a simple small version which loads 2 png files. It shows the problem though.
Just run it as it is and you should find task manager shows it steady at around 12mb (now and again goes lower but I assume that is Windows catching when you are clearing the sprite memory). Now rename the png files to something else and run again. It will now use the shoebox and you should see the memory being used up very quickly.
Hope that helps!
Cheers
[attachment deleted by admin]
Could you test it for SOUNDS and the other branch, media$?.
I'll see if I get a chance later. Got some chores to do! I know that when I used shoebox on the iphone originally I couldn't get wavs to play and had to store them separately. And that was with using the other branch too.
Cheers
No, there was not a single memory leak!
... there were TWO in one function. I'm so sorry. I'll pack that in the next update, which will be a big one.
Excellent :) Nice one Gernot, you are the man!
Cheers
If the next update isn't out soon then is there any chance we can get this fix before then? Also, does this fix also address the issues people are having using shoebox with sound files?
Thank you.
The problem is, that I changed a real lot already.
You "might" want the beta? http://www.glbasic.com/beta/glbasic_sdk.exe (http://www.glbasic.com/beta/glbasic_sdk.exe)
I do :)
Oooh, Beta shinyness.... Hmm, dunno though. Any idea of when it will be out of beta? Obviously can't give definite dates, but are we talking days, weeks, or (say it ain't so!) months?
Cheers
when it's done ?
No, I have no idea, yet. I hope it will be quick, but there's some issues with Android that have to be sorted before.
The more beta testers the quicker the final release :)
QuoteWhen you "draw" the sprite to an offscreen surface, draw with alphamode -1 to preserver the alpha bits
Just got round to testing that out. Brilliant that's a lot better for my blended sprites (see attached example).
However, I still don't know how to resize the sprites so that they use up less memory and CPU. ie. there is no point using full retina graphics on a lower resolution but I don't really want to have 2 lots of graphics to load (esp with new Android market looming and much more resolutions to handle). My previous code would resize and save out to a different directory and this worked fine, except I can't see how this would work with alphablended sprites as seen in my attachment. Surely pasting a sprite (stretchsprite) at a smaller size to the screen (as I do) and then grabbing it at the smaller size to then savesprite would lose all the different levels of transparency? If you paste onto pink, then that's one thing, but surely again only the exact (255,0,128) would be transparent and the semi-transparent stuff would be an off-pink that would stay that colour when loaded back in again? In other words how do I save an alphablended sprite in GLB so that it fully retains all the different levels of transparency, but it's now at a different size than the original sprite? eg. either loadsprite or savesprite with a different ratio percentage for both X and Y that will load or save a sprite at a set size. Much better for RAM and CPU then then stretch or zoom sprite. Or is there another way of doing this?
Cheers
[attachment deleted by admin]
One option is drawing your scene to a retina size image and scale down the whole thing down for non-retina devices? Obviously your X and Y co-ords would have to take into account the display differences. Scaling down is going to lose detail no matter what you do.
Another option is to release two versions - retina and non-retina.
As for Android, with so many different resolutions, there's not going to be one single/easy answer to any res problems.
Yes, that is what I did in the code I posted. Basically you have your media directory with everything at retina sized graphics. Then you check the resolution compared to retina. If it is retina then all is good, carry on. If not then load all graphics and stretch sprite them to a pink screen at the appropriate ratio to match retina for your current resolution, and then savesprite to a different directory. Once finished set the current directory to the different directory. This works fine with a demo app I made for the 3GS and the Touch 4G (Retina). Only thing that doesn't work is a PC where for some reason the saved PNG doesn't work with pink for transparent in GLB (even though is 100% correct RGB value). Just load into PSP and save it straight away and GLB works with it again. Strange, but don't care as this is for iPhone, and it works there.
However with alphablended sprites which have multiple levels of transparency (see above screenshots) then this method will not work. As far as I know (correct me if I am wrong), then grabsprite just uses the colours on the screen and doesn't care about actual transparency. So this is provided by pink (255,0,128). So how can I grab a sprite and retain the multiple levels of transparency? Either to then save as an alphablended png, or to store as a sprite in memory retaining the multiple levels of transparency. Then the sprite has the same transparency as it's bigger version, but is using up less memory and therefore must be less usage on the CPU/GPU when drawing it.
Overall though this is to reduce the time it would take to produce different sized graphics yourself. And with the massive potential different resolutions of different devices then you basically wouldn't have to worry about it. My initial code proves this, but it just stalls with alphablended sprites.
Cheers
QuoteYes, that is what I did in the code I posted. Basically you have your media directory with everything at retina sized graphics. Then you check the resolution compared to retina. If it is retina then all is good, carry on. If not then load all graphics and stretch sprite them to a pink screen at the appropriate ratio to match retina for your current resolution, and then savesprite to a different directory.
No, that's not what I meant at all.
You just load in the graphics for retina display and draw your WHOLE scene to a virtual screen.
So (CREATESCREEN ID_SCREEN,SPRITE_ID,960,640), then USESCREEN ID_SCREEN. Draw EVERYTHING to this screen, then USESCREEN -1, then scale down SPRITE_ID using POLYVECTOR (or ZOOMSPRITE, but that's slower). This way you aren't saving anything to anyhere and you still get all transparency etc.
will it be fast enough?
I've used createscreen before, but I don't quite get what you mean here. Would this allow alphablended sprites that are say 500x500 to be then loaded as sprites that are 250x250 (and not actually be stored as 500x500 behind the scenes which is what happens with stretch or zoom sprite for example)?
Or are you saying use this screen to draw everything at say 50% size then use that screen? Wouldn't that be pretty much the same as using stretchsprite with a 50% size on X and Y? Effectively you are still holding in memory the sprite at 100% size, and everytime you want to draw it at 50% then behind the scenes it would have to calculate every time to showing it at 50%. Or am I missing something?
Effectively at the end of the day I am looking for a routine that takes retina graphics and resizes them on the fly to the current resolution so it doesn't take up the same memory or processing power that keeping the actual retina graphics in memory would do (using stretchsprite at 50% every time you draw the sprite is still storing it at 100%). I did this before but it won't work with multiple levels of transparency.
Cheers
You open a "hidden" screen.
Createscreen 1,5,640,960
This screen (640x960) is both a screen (id 1) and a sprite (id 5 in my example).
When you use USESCREEN 1, everything you draw is drawn into this screen/sprite, not in the backbuffer. Once you finish your drawing operations, you use USESCREEN -1 to draw again in the backbuffer: it is time to use STRECTSPRITE 5,0,0,320,480 to draw the sprite id 5 (remember, it was also a "screen") resized to the "real" screen.
Createscreen 1,5,640,960 //retina screen
usescreen 1 //draw on the previous created screen
drawsprite 1,100,100 //draw something in this screen
print "Works!",10,200 //something else to be drawn
usescreen -1 /go back to the real backbuffer
strectsprite 5,0,0,320,480 //draw the sprite downscaled, you can use also zoomsprite or polyvector
showscreen
there was also a command to disable background cleaningm but I dont remember. That way screen refresh is faster.
If you draw everything at full size onto the canvas (virtual screen), then scale that canvas down you are only scaling once. You are not scaling the sprite, only the virtual screen that all the sprites are on.
This should still be very fast using POLYVECTOR (although this will depend on how much drawing is done to the virtual screen).
LOCAL frames_per_second
// Set main game screen at 640,480 res
SETSCREEN 640,480,0
// Create a virtual screen that is twice as large as game screen
CREATESCREEN 1,999,1280,960
// repeat
WHILE TRUE
// Use the virtual screen for drawing
USESCREEN 1
// Draw 100 rectangles each frame
FOR n=0 TO 100
DRAWRECT RND(1280),RND(960),32,32,RGB(RND(255),RND(255),RND(255))
NEXT
// Set drawing to proper visible screen
USESCREEN -1
// Ensure non anti-alias
SMOOTHSHADING FALSE
// Draw image of virtual screen, but scaled by half
STARTPOLY 999
// //Pos+dimenson // Virtual screen dimensions
POLYVECTOR 0,0, 0,0
POLYVECTOR 640,0, 1280,0
POLYVECTOR 640,480, 1280,960
POLYVECTOR 0,480, 0, 960
ENDPOLY
// Proof that the original screen is being scaled by 1/2 - Black rect is twice the size of small rects.
DRAWRECT 200,200,32,32,RGB(0,0,0)
// calculate and show FPS
frames_per_second=FPS()
PRINT "FPS="+frames_per_second,10,10
SHOWSCREEN
WEND
// FPS counter
FUNCTION FPS:
STATIC OldTimeReport$,FPSDat,TimeReport$,FPSd
OldTimeReport$=TimeReport$; FPSDat=FPSDat+1;
TimeReport$=PLATFORMINFO$("TIME")
IF OldTimeReport$<>TimeReport$; FPSd=FPSDat ; FPSDat=0; ENDIF
RETURN FPSd
ENDFUNCTION
That code shows the virtual screen being blitted by 100 rects (using DRAWRECT, which is slower than drawsprite). The virtual screen is then scaled to fit the actual/visible screen and displays a black rect to prove that the scaled screen is exactly half of the original image (do a screen capture and measure the small rects and large). It also shows FPS, which should stay at a constant 60FPS.
There's no alpha transparency involved in the example, but it doesn't matter. The scaled image will look EXACTLY like the original image, just reduced in size.
I get what you are saying but surely putting everything onto a virtual screen won't be as fast as just drawing a correctly resized sprite directly to the backbuffer? Plus if you are doing this on a moving sprite or a changing background then aren't you creating this virtual screen everytime from the same retina sized sprites? So you are still holding the full sized sprites in memory. If the original sprite is 500x500 for retina, then I really only want a 250x250 sized sprite loaded into memory on devices below retina. Otherwise it's a waste of memory. I don't see the point of loading and then rescaling a sprite or a virtual screen when you can have the original 500x500 sprite, and also the 250x250 sprite (automatically resized and saved) and it knows to use 250x250 when not on retina. This is no different to actually using 2 sets of sized sprites that you create yourself and choose in the program based on resolution, but why not make it do it automatically (like I did earlier just not with alphablend) and cover other resolutions while you are at it?
Cheers
You can't have it both ways - low memory usage (with only one set of sprites) and/or scaling larger to smaller without some sort of payoff. You could have two different apps with different sized images if you like (which will cost you more of your own time (redrawing everything twice) than GLB doing it in real-time), but what you want you can't have in the manner that you initially stated.
My example above is plenty fast enough with a hundred low-speed DRAWRECTs. Having your sprites animating and the game running will have an effect, but with careful management it shouldn't be an issue at all. And remember if you use POLYVECTOR and POLYNEWSTRIP you could draw thousands of sprites on screen quicker than just using DRAWSPRITE, even on iDevice.
The method I'm describing is purely to save memory when on a lower resolution device. I already wrote a simple program that resizes sprites so that everything is the correct ratio using smaller sprites on non-retina. And it all looks and runs perfectly fine. I run it on either retina or non-retina devices and they look identical from one set of retina sized graphics (obviously the lower resolution device will not look as smooth). But the retina device has the graphics full sized in memory whereas the non-retina device is using a lot less memory with the resized sprites.
The only thing missing is grabsprite (and from my example savesprite) does not include the correct opacity settings from the original sprite. Obviously it cannot as it just grabs what is on the screen. Opacity is only really measured by making pink into fully transparent. Not good enough for alphablended sprites with multiple levels of opacity. If there is another method to load a sprite, resize it, save it in the new size but keep the opacity information then great, that's what I want. I'm not bothered with losing anything detail wise as you obviously do that when going to a smaller resolution, but keeping the different opacity information I do want! This is why if it cannot currently be done I wanted to know if Gernot could modify the savesprite command to save a loaded sprite at a specific size (both X and Y ratios given separately). This way you could load the sprite, keeping all it's opacity levels as it does now, get the X and Y ratio for the resolution and save out the new resized sprite at those ratios to create a new smaller sprite that has the originals opacity info. From then on the app can load the smaller sprites you saved on initial installation, so saving memory. Working out coords and mouse positions and the like are pretty easy after that.
Cheers