Jump to content


Photo

Custom external sprite handling & drawing [GM:S]


  • Please log in to reply
97 replies to this topic

#51 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 08 January 2016 - 10:00 AM

I am not doing anything very wrong man, I am doing a fighting game with HD sprites. It's not a Tetris or a 16 bit pixel art game, it's 2D and HD. I know what I'm doing. Why are you judging without even knowing the project ?

 

Each character has a lot of animation frames, and that takes a lot of memory. The game has to load character1 + character2 + stage background + hud/misc texturegroups in fight, because any realtime loading is going to mess up everything, the game must not slow down.

 

At least admit your system is taking four times more ram that usual for each texturepage, instead of blaming me for using it. Your framework would mainly be useful for games that are heavy on graphics, because they wouldn't need to unload otherwise (except if doing a mario like platformer with ten thousands of different level skins, which I highly doubt that will even exist).

 

pQIRlMf.gif

This is an example of sprite. It's only one animation of thirty or something like this. All the normal moves, special moves, roll, dash, jump and stuff take a lot of memory.

In the golden era of fighting game, developers were adding memory cartridge on CD consoles to handle the big loads of sprites. This is the most memory-consuming 2D genre.

 

But im not doing cinematics ...

Also, consuming half the memory, having some freeze when resizing or fullscreening and taking a bit more time to draw is less important than wasting so much ram imo.


Edited by Shamanovitch, 08 January 2016 - 10:06 AM.

  • 0

#52 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 08 January 2016 - 01:59 PM

 

 

At least admit your system is taking four times more ram that usual for each texturepage, instead of blaming me for using it.

I never denied that, and I am aware of that. That is a problem which happens due to GM memory usage when adding new backgrounds or sprites. Didn't mean to sound as if I was blaming you, I was just claiming that if you are using sprites for video scenes, etc then you should change things but you aren't doing that so it's fine.

 

Coming back to the original problem, I see your point and if you had ~425x425 sprites for characters, each with 10 animations and 18 frames per animation that would take up 7650x4250 pixels which already creates quite a large problem. Because you have a fighting game I assume that you aren't going to use too many data structures and can use a bit more memory for graphics. But even if you allocated a single 8192x8192 (512mb) texturepage and had the specified amount of character animations,etc then you would barely have any room left on the texturepage for anything else.

 

That would mean that you'd have to cut down on how many different character sprites and scene sprites you have. That would obviously not be a good thing.

 

I will make a separate version of the image framework that uses surfaces and stores backups of them for reloading in a temp directory on the PC. I will probably get it done by tomorrow. (it will also include the draw_image_pos_ext,draw_image_pos_general,etc)


Edited by Braffolk, 08 January 2016 - 02:05 PM.

  • 0

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#53 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 08 January 2016 - 02:21 PM

Sorry then, I think I misinterpreted your post ! I thought you were telling me that my point was unrealistic and that I had no way to do it.

I will probably use some large sprites for some scenes or something, but that will be done with a proper loading/unloading since a cutscene doesn't need to have every characters' moves loaded. But that's out of topic !

Using the raw background_add, yes 8192x8192 would be 512, but that is halved with surfaces (and that would be awesome if GM lets us compress added assets like they do, would mean 8192 = 128mb and now we can start having room to do epic things). Actually I think a character would need something like 2 or 3 pages like this, that's a lot, but if GM can compress textures without quality loss, there has to be a way to do that ! Maybe something like a DLL or what ? But we enter in a domain I absolutely don't know and I wouldn't ask you to check that for your awesome framework.

 

So I am going to mostly use the memory for graphics yes !

Let's see if everything fits with the surface version (thank you very much by the way, I was trying to edit myself but didn't manage to get past the cache file creation, too much errors). If not, I'll kill myself or make a blood pact with a demon to find a way.


  • 0

#54 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 08 January 2016 - 02:28 PM

Using the raw background_add, yes 8192x8192 would be 512, but that is halved with surfaces (and that would be awesome if GM lets us compress added assets like they do, would mean 8192 = 128mb and now we can start having room to do epic things).

I could've written a DLL for it but that would mean that it's not multi platform anymore. I will post a suggestion in the suggestion box for compression for externally added sprites/backgrunsd. Maybe they will accept it.

 

Edit: The topic http://gmc.yoyogames...howtopic=687389

 

Edit 2: Just keep in mind that using surfaces will be way slower.


Edited by Braffolk, 08 January 2016 - 03:02 PM.

  • 0

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#55 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 08 January 2016 - 03:29 PM

Nice ! Let's hope it happens !

As said in private, I'm really interested in a DLL even if that sacrifices the multiplatform aspect.

Cheers


  • 0

#56 rwkay

rwkay

    YoYo Games CTO

  • YoYo Games Staff
  • 2937 posts
  • Version:Unknown

Posted 08 January 2016 - 03:48 PM

OK the problem here is that you cannot have compression of textures (which is what externally loaded assets are) without compromising on the quality as all compression schemes for textures (that are supported in hardware) are lossy and really designed for 3D textures not 2D games.

 

we cannot do what you ask as the hardware does not support it.

 

I would look at using SWF sprites for the animations or Spine so that the number of images can be cut down a lot without necessarily compromising the animation.

 

Russell


  • 0

#57 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 08 January 2016 - 04:01 PM

OK the problem here is that you cannot have compression of textures (which is what externally loaded assets are) without compromising on the quality as all compression schemes for textures (that are supported in hardware) are lossy and really designed for 3D textures not 2D games.

 

we cannot do what you ask as the hardware does not support it.

 

I would look at using SWF sprites for the animations or Spine so that the number of images can be cut down a lot without necessarily compromising the animation.

 

Russell

Hello, thanks for your answer. I am then wondering how adding a background of for example 4096x4096 in included file in GM takes half memory than adding a background via an external file, without quality loss ?

Is it a software compression at the runner loading ?

There has to be a way to use this on an external asset imo.

Also, how much is "lossy" ? :D


Edited by Shamanovitch, 08 January 2016 - 04:07 PM.

  • 0

#58 rwkay

rwkay

    YoYo Games CTO

  • YoYo Games Staff
  • 2937 posts
  • Version:Unknown

Posted 08 January 2016 - 04:13 PM

When the asset is present in our WAD file (containing the compiled game assets then we store the RAM version as a PNG so that is compressed) when we load an external image then we keep it as a texture that is full 32bit this is then given to D3D which will keep an in memory image and a VRAM copy as well so the memory usage is much higher for externally loaded images.

 

This is not a simple thing to change and I would highly encourage you to use pre-compiled images as much as possible.

 

Russell


  • 0

#59 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 08 January 2016 - 04:56 PM

Well I found a potential workaround for this. I may be able to write it so that all of the images are compressed (using a custom compression algorithm) vertex buffers, this would allow way greater control over memory usage and the image format itself. I still don't know how fast it would be or how much memory it would use, i'll post the results once i've done proper testing on this.

 

Edit:

Getting great results, the average memory usage for a 4096x4096 image using vertex buffers is around 50mb (256mb with GM external sprites). This varies depending on how complex the image is and how many colours it has, but even then it will take way less memory than GM backgrounds.

 

The current compression method is extremely basic but relatively fast, it generates a list of points for similar colours out of the loaded image and adds them to the vertex buffer that uses a custom format and a shader to display it. This is quite fast as long as the size of the sprites don't go too much over 3000x3000.

 

Points of an image:

dGqAKcv.png

 

And the whole image(rendered):

5DJh5Xf.png

 

Now the downside of this is mainly the fact that you can't get textures from this, so if I created another version using vertex buffers then you wouldn't be able to get a texture from it.


Edited by Braffolk, 08 January 2016 - 09:55 PM.

  • 0

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#60 chreechokash007

chreechokash007

    GMC Member

  • GMC Member
  • 230 posts
  • Version:GM:Studio

Posted 12 January 2016 - 08:18 PM

That's a very great extension. Just one thing i would like to know. Why each 2048x2048 texture page consuming about 35 mb of memory? GM inbuilt texture paging system consumes a lot less per 2048x2048 texture page. I am a noob so i want to know the reason.


  • 0

#61 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 12 January 2016 - 11:51 PM

Honestly the memory usage for an extra texture page isn't that terrible. I am working on a game that is 1080p game and found the best solution is to just keep player animations, and everything else that does not need to be loaded externally, internal. I have an entire mod system and I am having no issues with memory. :P


  • 0

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#62 HopelessComposer

HopelessComposer

    GMC Member

  • GMC Member
  • 1337 posts
  • Version:GM:Studio

Posted 13 January 2016 - 12:45 AM

Honestly the memory usage for an extra texture page isn't that terrible. I am working on a game that is 1080p game and found the best solution is to just keep player animations, and everything else that does not need to be loaded externally, internal. I have an entire mod system and I am having no issues with memory. :P

I'm not an expert or anything, so I'm not going to argue either way, but your game looks just a liiiiiiiiiiittle bit different than Shamonovitch's.


  • 0

#63 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 13 January 2016 - 02:29 AM

I agree but what I'm saying is that if he organizes his texture pages and uses the internal sprite system, he would be just fine.


  • 0

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#64 HopelessComposer

HopelessComposer

    GMC Member

  • GMC Member
  • 1337 posts
  • Version:GM:Studio

Posted 13 January 2016 - 02:46 AM

That might be true - I have no idea, hahaha! =D

My point was just that even though your game is 1080p doesn't make it a good comparison. Like he said, he's using huge sprites, while you're using mostly tiles. It feels like he'd have more trouble with this kind of thing than you or me.


  • 0

#65 zbox

zbox

    GMC Member

  • GMC Member
  • 2618 posts
  • Version:Unknown

Posted 13 January 2016 - 05:10 AM

Honestly the memory usage for an extra texture page isn't that terrible

It kind of actually is - especially if you load say 50 small facebook profile pictures to display on a leaderboard. Also in game, the performance loss from texture swaps is huge


  • 0

#66 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 13 January 2016 - 05:18 AM

Why would you store each picture on a separate page? That is the advantage of using the external system Braffolk has put together. You can put 50 small pictures onto one page and reduce 50 pages to 1, and a single swap. I'm saying 3-5 external pages isn't going to be the end of the world in terms of memory. Most computers now-a-days have AT LEAST 2gb of RAM.


Edited by cookieboy, 13 January 2016 - 05:18 AM.

  • 0

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#67 zbox

zbox

    GMC Member

  • GMC Member
  • 2618 posts
  • Version:Unknown

Posted 13 January 2016 - 05:36 AM

You wouldn't, you'd use a system like this which is my point? It seemed like you were saying not to bother and use the default way.


  • 1

#68 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 13 January 2016 - 06:28 AM

Oh of course not xD


  • 1

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#69 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 15 January 2016 - 10:35 AM

I agree but what I'm saying is that if he organizes his texture pages and uses the internal sprite system, he would be just fine.

Impossible :D

Just 2 characters at the same time are already almost at max memory. There's no way characters that aren't on screen have to take some memory !

And you're not even accounting the stages, which also have a lot of characters (npc) with a lot of animation frames.

Also i'm using surfaces heavily to make special effects with shaders. My game is memory hungry.

Just forget that option haha

Let's see what Braffolk can do with this compression system but I think it will be perfect for my game.

 

A wip of the game. you can see the stage and some fx :

https://www.youtube....h?v=FUBXVwmMPf4

 

As you can see it's nowhere near your game in term of graphics hahaha

 

 

That's a very great extension. Just one thing i would like to know. Why each 2048x2048 texture page consuming about 35 mb of memory? GM inbuilt texture paging system consumes a lot less per 2048x2048 texture page. I am a noob so i want to know the reason.

From what I understood from the devs, they said they compile the whole game assets in a single file which is sent to memory. I think it's a kind of zip file which is resident in memory (.wad file) and they can load from it when you display something. Whereas an added texturepage is a raw image loaded into mem. I guess it's impossible to throw the added texturepage into their compressed thing during gameplay.


Edited by Shamanovitch, 15 January 2016 - 10:43 AM.

  • 0

#70 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 15 January 2016 - 06:59 PM

Wait, why do you have multiple animations for background characters? That is a huge waste of memory.  Just compile them in with the background where you can. That alone will save you like, 30 texture pages.


  • 0

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#71 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 15 January 2016 - 11:39 PM

Lol ok
Please do not give useless advice here, I dont think you really know what you're doing ...
Lets Just wait for the new version.

Edited by Shamanovitch, 15 January 2016 - 11:44 PM.

  • 0

#72 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 16 January 2016 - 01:36 AM

Lol ok
Please do not give useless advice here, I dont think you really know what you're doing ...
Lets Just wait for the new version.

His new version won't solve your problem and if you think that my suggestion is so useless, please provide to me your logic as to why it was not a good suggestion.


  • 0

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#73 chreechokash007

chreechokash007

    GMC Member

  • GMC Member
  • 230 posts
  • Version:GM:Studio

Posted 16 January 2016 - 10:00 AM

I would love to see texture control along with texture compression to save memory. Each 2048X2048 texture page is taking about 35mb of memory right now.


  • 0

#74 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 16 January 2016 - 10:23 AM

 

Lol ok
Please do not give useless advice here, I dont think you really know what you're doing ...
Lets Just wait for the new version.

His new version won't solve your problem and if you think that my suggestion is so useless, please provide to me your logic as to why it was not a good suggestion.

 

Since the beginning you are talking crap, telling first that with texture management it wouldn't be a problem, without even knowing how much texturepages the whole character count would take.

First of all, texture management wouldn't change anything for the ram, as all the textures are sent to memory at game start. You make 2 groups, you make 18 groups, you make 500 groups if you want, it doesn't change anything. It's even a bit worse because with texturegroups you often end with some pages being emptier than the others, whereas without any group GM fills the pages the best it can. So basically you said crap for that.

 

Then you say that of course not, it's not good to use the internal system and a texture doesn't take that much memory. That is because your game uses 3 or 4 texturepages per level. I've went to see your game, it looks terrible. You argue that it's 1080p, but it's completely empty, the tiles are as small as a 320p game, and every sprite is barely even noticeable since it's so small. So yeah, you won't have the problem I have, because your game is not intensive at all on graphics. So another crap you said here.

(Also why are you even comparing your game to mine ? It's insulting for me)

 

Last, you now argue that putting the background characters as tiles would take less space/memory than using sprites. This is nonsense. If the characters are moving on the background, and have collisions on them, that means they can't be fused with the background. And if the animations have to be kept as tiles, that means it will take the same amount of space than as sprites. So even another crap there.

 

And ... Of course all these are absolutely not solving the problem which is doing too much characters and having their sprites sitting in memory for fights they are not involved into is pure waste.

So ... Braffolk is going to make a new version where each loaded page will take much much less memory thanks to the compression, which will allow to load multiple pages without hitting the game limit. His new version IS going to solve the problem, you said crap again.

 

Please don't try to handle it, even Braffolk himself understood and is working on this whereas you are endlessly suggesting random things. I'll do what I think it's good and ignore you from now on. Enjoy creating your game, kisses


Edited by Shamanovitch, 16 January 2016 - 03:04 PM.

  • 0

#75 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 16 January 2016 - 05:44 PM

What? Perhaps you did not understand what I suggested. I never used the word "tiles" in my last suggestion. I said background. Tiles I agree would be useless in this case. Also before you talk craps on somebody else's work, perhaps do some reading first, http://steamcommunit...113709031601687

I don't know why you are being so rude but nobody on the GMC wants to help someone who insults them.

I never suggested you use internal sprites for every character. I suggested you resort to internal images for a lot of other stuff though as it would save a lot of memory.

Finally, insult my work all you want but I don't see anything you've done selling anywhere. Maybe treat others nicely.
  • 1

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#76 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 17 January 2016 - 02:18 PM

Release 2.6

  • Added draw_image_pos_ext(image,subimg,x1,y1,x2,y2,x3,y3,x4,y4,rot,col,alpha)
  • Added draw_image_pos_general(image,subimg,x1,y1,x2,y2,x3,y3,x4,y4,rot,c1,c2,c3,c4,alpha)
  • Added draw_image_tiled_area(image,subimg,x1,y1,x2,y2)
  • Added draw_image_tiled_area_ext(image,subimg,x1,y1,x2,y2,xscale,yscale,colour,alpha)

Documentation: Onedrive link
Scripts: Onedrive link | Filedropper link Extension: Onedrive link | Filedropper link
 
No gml_pragma (slower, for older GM versions that dont have gml_pragma):
Scripts Onedrive link Extension Onedrive link
If you have any suggestions or find any bugs please let me know because otherwise they may not be included or fixed.

 

 

New image framework:

Spoiler

  • 3

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#77 zbox

zbox

    GMC Member

  • GMC Member
  • 2618 posts
  • Version:Unknown

Posted 20 January 2016 - 03:06 AM

Out of interest what situations do you use the inline compilation and how much faster does it make things?

 

Very excited about that new image framework too. Would be really pleased if you released a donation version on the marketplace or something this is a fantastic project.


  • 2

#78 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 20 January 2016 - 03:36 AM

I have a suggestion. A texture page save and load function would be amazing. Perhaps it would save the texture page (background_save()) that would also save the stored information for sprite calls, this would reduce future loading time by quite a bit I'd imagine. I could be wrong though.


  • 0

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#79 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 21 January 2016 - 02:54 PM

I have a suggestion. A texture page save and load function would be amazing. Perhaps it would save the texture page (background_save()) that would also save the stored information for sprite calls, this would reduce future loading time by quite a bit I'd imagine. I could be wrong though.

This is exactly what the image cache is for. Except you have to save groups, not texturepages. I can't add functionality to save an individual texturepage because some of the data of the texturepage may be on another texturepage.


  • 2

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#80 deciia2015

deciia2015

    GMC Member

  • New Member
  • 10 posts
  • Version:GM:Studio

Posted 23 January 2016 - 12:11 PM

image_stream_finish

line58:

if( _min_area_id != -1 ){
            n = _min_area_id;
            draw_sprite_part( _spr , i , 0  , 0 , subimg_w , sprite_get_height( _spr ) , _l_areas[| n ] , _l_areas[| n + 1 ] );
 
------------------------------
it need preset color and alpha,or use draw_sprite_part_ext,or it may draw image with alpha and color that set in other code.
when load large images,it will out of memory,and it is not easy to add sprite with lots of sub images.

Edited by deciia2015, 23 January 2016 - 12:14 PM.

  • 0

#81 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 23 January 2016 - 01:55 PM

 

<snip>

it need preset color and alpha,or use draw_sprite_part_ext,or it may draw image with alpha and color that set in other code.
when load large images,it will out of memory,and it is not easy to add sprite with lots of sub images.

 

How large images are those exactly?

I'll fix the alpha and colour bug.


Edited by Braffolk, 23 January 2016 - 01:56 PM.

  • 1

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#82 deciia2015

deciia2015

    GMC Member

  • New Member
  • 10 posts
  • Version:GM:Studio

Posted 23 January 2016 - 11:36 PM

4500*1440

I have a idea.First,use sprite_add add single sub images,and then use sprite_merge merge to a whole sprite,then add them all to texpage 


  • 0

#83 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 24 January 2016 - 01:17 AM

That wouldn't change anything, the memory usage would stay the same.

 

GM uses 8 bytes per pixel for externally loaded textures. Why are you using sprites larger than a lot of screens? It will lag on quite a few lower end GPUs with sprites that large.

 

Also make sure that your texture pages are smaller ( or equal to) 8192x8192 but even with 8192x8192 you might have quite a few problems.


  • 1

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#84 chreechokash007

chreechokash007

    GMC Member

  • GMC Member
  • 230 posts
  • Version:GM:Studio

Posted 30 January 2016 - 04:40 PM

Hey there is some problem in texture making algorithm. Why it's leaving so much space blank and jump to creating new texture page? It's not efficient at all. It just wastes a lot of space for no reason. Please can you improve it?


  • 0

#85 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 30 January 2016 - 05:21 PM

I think it's more important if he does the texture compression algo instead, let's let him time for that, it will save more memory than the bit of blank pages


  • 0

#86 cookieboy

cookieboy

    Seabass (The Human)

  • GMC Member
  • 747 posts
  • Version:GM:Studio

Posted 30 January 2016 - 05:37 PM

Hey there is some problem in texture making algorithm. Why it's leaving so much space blank and jump to creating new texture page? It's not efficient at all. It just wastes a lot of space for no reason. Please can you improve it?

I'd trade left over white space for a faster algorithm in some cases. You got to consider the trade offs.


  • 1

Vnc5NxB.jpg

Support a fellow GMC member? <3

http://store.steampo...com//app/357650


#87 chreechokash007

chreechokash007

    GMC Member

  • GMC Member
  • 230 posts
  • Version:GM:Studio

Posted 30 January 2016 - 05:57 PM

Has anyone tested this on Android? For me it's causing memory leak of 8mb on 2048x1024 texture page and 16mb on 2048x2048 texture page, when we delete the group using image_group_destroy(). Means it's not clearing the memory fully. I am giving an example. I have a project consuming 40mb of ram. Now when i make texture page of 2048X1024 and memory consumption will reach 66mb. When i try to destroy the image group using image_system_cleanup() or image_group_destroy(), memory consumption will go down to 48mb and not 40mb. But, when you again make a new texture group of 2048X1024 and destroy it, it won't go beyond 48mb. Please fix this issue.


Edited by chreechokash007, 31 January 2016 - 09:34 AM.

  • 0

#88 blovestorm

blovestorm

    GMC Member

  • GMC Member
  • 28 posts
  • Version:GM:Studio

Posted 01 February 2016 - 03:26 AM

very very good!!!
  • 0

#89 autukill

autukill

    GMC Member

  • GMC Member
  • 144 posts
  • Version:GM:Studio

Posted 01 February 2016 - 12:14 PM

I have a test:

 

I use this script to load my game all the pictures (12.5MB), The entire game memory usage reaches 550 + MB.

 

I save this texture group ( image_cache save() ), the resulting file is only 13MB

 

 

I using the original texure page system, the whole game is running, picture resources takes about 40MB, does not include other resources, such as sound and program codes.

 

What is the reason? I see you mentioned image compression

 

:confused:


  • 0

#90 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 02 February 2016 - 09:49 AM

Please read it's because textures loaded externally are taking much more memory than included textures at the moment. He's working on a thing to load externally and have it take about as much, using compression.

Cheers


  • 0

#91 autukill

autukill

    GMC Member

  • GMC Member
  • 144 posts
  • Version:GM:Studio

Posted 02 February 2016 - 09:59 AM

Please read it's because textures loaded externally are taking much more memory than included textures at the moment. He's working on a thing to load externally and have it take about as much, using compression.

Cheers

I understand what you mean now.

Cheers


  • 1

#92 chreechokash007

chreechokash007

    GMC Member

  • GMC Member
  • 230 posts
  • Version:GM:Studio

Posted 02 February 2016 - 12:57 PM

Is there anyway i edit the saved buffers for image_cache_save? I want to edit the position of images placed in texture page manually. Is that possible?


  • 0

#93 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 02 February 2016 - 05:16 PM

Is there anyway i edit the saved buffers for image_cache_save? I want to edit the position of images placed in texture page manually. Is that possible?

Yes that is possible, but not the easiest task. I'm looking into making the texture sorting algorithm more efficient.

 

 

 

 

On a general note, I'm pretty much stuck with the image compression algorithm, it works perfectly fine, however, it is simply too slow (takes 10 minutes for a 512x512 more complex image). I am still looking into alternatives but this is definitely taking longer than expected.


Edited by Braffolk, 02 February 2016 - 05:17 PM.

  • 1

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#94 chreechokash007

chreechokash007

    GMC Member

  • GMC Member
  • 230 posts
  • Version:GM:Studio

Posted 02 February 2016 - 07:24 PM

It takes 10 minutes for generating positions in texture page right? That means once they are generated then from cache we can create it fast the next time? Also we can include cache from the beginning in our game so that it won't take any time. You have to release the slow version now. Then keep improving it.


  • 0

#95 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 02 February 2016 - 07:52 PM

No, it takes 10 minutes to convert the image into the custom vertex buffer format that I created with the smallest size possible.

You can load the converted ones in super quickly but now if you had custom content for your game you really wouldnt want to convert all of your users images because that would take forever for them.


Edited by Braffolk, 02 February 2016 - 07:54 PM.

  • 0

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#96 Shamanovitch

Shamanovitch

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 03 February 2016 - 12:48 PM

Damn !!

Did you try with the texturepage I sent you ? It's a rather complex one and 4196 IIRC

Maybe there's another solution to compress the images in memory, like the .wad compressed file GM creates (is that thing related to vertex buffers ?)


  • 0

#97 Annoyed Grunt

Annoyed Grunt

    Right behind you.

  • GMC Member
  • 884 posts
  • Version:GM:Studio

Posted 15 March 2016 - 03:37 PM

Hello!
I wanted to warn everybody that could be having my same problem: using image_stream_finish does not work in HTML5 for now (I'm using version 1.4.1749) because using background_create_colour halts the event, meaning that nothing after it (or the function itself) will execute at all!

 

It's took me hours to point it down, and I've already submit a bug ticket.

EDIT: actually I think the function itself is ran, considering I got a few "out of memory" messages by putting it in step.


Edited by Annoyed Grunt, 15 March 2016 - 03:45 PM.

  • 0

Every time somebody uses the term "Roguelike" improperly I cry.

Spoiler

#98 Annoyed Grunt

Annoyed Grunt

    Right behind you.

  • GMC Member
  • 884 posts
  • Version:GM:Studio

Posted 17 March 2016 - 05:25 PM

Braffolk, do you think you could implement an import of sprites at different resolutions? For example, it's useless to import a superhd sprite if the current resolution is much smaller. I suppose in order to implement this you'd have to use a second surface onto which draw the first surface (but stretched to a different size) before converting the second surface to a background.

Also, do you have a donation button or something?


  • 0

Every time somebody uses the term "Roguelike" improperly I cry.

Spoiler