6 Formatted for easier readability; minor grammar and punctuation; removed blacklisted engine tag
source | link

How todo we solve the big video memory requirements in 2da 2D game?

How do we solve big video memory requirements in a 2D game?


We are developing 2da 2D game (Factorio) in allegro C/C++, and we are facing thea problem with increasing video memory requirements as the game content increases.

What weWe currently do is, that we gather all the info about picturesimages that are going to be used first, crop all of these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and, the size of thosewhich depends on the system limitations,limitations; currently it is usually 2 picturesimages of up to 8192X81928192x8192, so they require more than 256Mb and less thanto 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands picturesof images on the screen in 60 fps, asfps; we have manymany objects on the screen, and allow quiteallowing a big zoom-out this is a critical requirement.

But as As we would like more to be addedadd more, there is going to be some trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common thingsimages, and the second would work as a cache, the pictures. The images would be moved there from the memory bitmap, on demand. There are 2two problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow, in allegro.
  2. It is not possible to work with video bitmap in other than the main thread, in allegro, so it is practically not usableunusable.

So here is the questions:

  • What would you recommend we do to solve this in our 2D game with lots of resources?
 

Edit: Adding Here are some additional requirements that we have in the game.:

  • The game must be determistic, so the performance issues/loading times can never alter the game state. The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs. The game is real time, and soon to be multiplayer, as well. We need to avoid even the smallest stutter at all costs.
  • Most of the game is one continuous open world Most of the game is one continuous open world.

Edit: I made some measurements.

 

The test consisted of drawing 10 000 sprites in a batch for sizes from 1X11x1 to 300X300300x300, several times for every configuration. I did the tests on the Nvidia Geforce GTX 760.

  • Video bitmap to video bitmap drawing took 0.1us per sprite, when the source bitmap wasn't changing between individual bitmaps (atlasthe atlas variant),; the size didn't matter
  • Video bitmap to video bitmap drawing, while the source bitmap was switched between drawings (nonon atlas variant), took 0.56us per sprite,sprite; the size didn't matter, either.
  • Memory bitmap to video bitmap drawing was really suspicious. SizeSizes from 1x1 to 200X200200x200 took 0.3us per bitmap, so not so horribly slow. For larger sizes, the time started to raise very dramatically (9us, at 9us for 201X201201x201 to 3116us for 291X291)291x291.

Conclusion. UsingUsing atlas increases the performance by a factor greater than 5. If I had 10ms for the rendering, with an atlas I'm limited to 100 000 sprites per frame, and without it the, a limit of 20 000 sprites. This would be problematic.

How to solve the big video memory requirements in 2d game

We are developing 2d game (Factorio) in allegro C/C++ and we are facing the problem with increasing video memory requirements as the game content increases.

What we currently do is, that we gather all the info about pictures that are going to be used first, crop all these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and the size of those depends on the system limitations, currently it is usually 2 pictures up to 8192X8192, so they require more than 256Mb and less than 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands pictures on the screen in 60 fps, as we have many objects on the screen and allow quite big zoom-out this is critical requirement.

But as we would like more to be added, there is going to be trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common things, and the second would work as cache, the pictures would be moved there from memory bitmap on demand. There are 2 problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow in allegro.
  2. It is not possible to work with video bitmap in other than the main thread in allegro, so it is practically not usable.

So here is the questions:

  • What would you recommend we do to solve this in our 2D game with lots of resources?

Edit: Adding some requirements that we have in the game.

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs.
  • Most of the game is one continuous open world

Edit: I made some measurements.

The test consisted of drawing 10 000 sprites in a batch for sizes from 1X1 to 300X300 several times for every configuration. I did the tests on the Nvidia Geforce GTX 760.

  • Video bitmap to video bitmap drawing took 0.1us per sprite when the source bitmap wasn't changing between individual bitmaps (atlas variant), the size didn't matter
  • Video bitmap to video bitmap drawing, while the source bitmap was switched between drawings (no atlas variant), took 0.56us per sprite, the size didn't matter either.
  • Memory bitmap to video bitmap drawing was really suspicious. Size from 1x1 to 200X200 took 0.3us per bitmap, so not so horribly slow. For larger sizes, the time started to raise very dramatically (9us for 201X201 to 3116us for 291X291).

Conclusion. Using atlas increases the performance by factor greater than 5. If I had 10ms for the rendering, with atlas I'm limited to 100 000 sprites per frame, without it the limit of 20 000 sprites would problematic.

How do we solve big video memory requirements in a 2D game?

How do we solve big video memory requirements in a 2D game?


We are developing a 2D game (Factorio) in allegro C/C++, and we are facing a problem with increasing video memory requirements as the game content increases.

We currently gather all the info about images that are going to be used first, crop all of these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory, the size of which depends on the system limitations; currently it is usually 2 images of up to 8192x8192, so they require 256Mb to 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands of images on the screen in 60 fps; we have many objects on the screen, and allowing a big zoom-out is a critical requirement. As we would like to add more, there is going to be some trouble with the video memory requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common images, and the second as a cache. The images would be moved there from the memory bitmap, on demand. There are two problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow, in allegro.
  2. It is not possible to work with video bitmap in other than the main thread, in allegro, so it is practically unusable.
 

Here are some additional requirements we have:

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is real time, and soon to be multiplayer, as well. We need to avoid even the smallest stutter at all costs.
  • Most of the game is one continuous open world.
 

The test consisted of drawing 10 000 sprites in a batch for sizes from 1x1 to 300x300, several times for every configuration. I did the tests on the Nvidia Geforce GTX 760.

  • Video bitmap to video bitmap drawing took 0.1us per sprite, when the source bitmap wasn't changing between individual bitmaps (the atlas variant); the size didn't matter
  • Video bitmap to video bitmap drawing, while the source bitmap was switched between drawings (non atlas variant), took 0.56us per sprite; the size didn't matter, either.
  • Memory bitmap to video bitmap drawing was really suspicious. Sizes from 1x1 to 200x200 took 0.3us per bitmap, so not so horribly slow. For larger sizes, the time started to raise very dramatically, at 9us for 201x201 to 3116us for 291x291.

Using atlas increases the performance by a factor greater than 5. If I had 10ms for the rendering, with an atlas I'm limited to 100 000 sprites per frame, and without it, a limit of 20 000 sprites. This would be problematic.

    Notice removed Draw attention by Community
    Bounty Ended with Kromster's answer chosen by Community
5 added 1169 characters in body
source | link

We are developing 2d game (Factorio) in allegro C/C++ and we are facing the problem with increasing video memory requirements as the game content increases.

What we currently do is, that we gather all the info about pictures that are going to be used first, crop all these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and the size of those depends on the system limitations, currently it is usually 2 pictures up to 8192X8192, so they require more than 256Mb and less than 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands pictures on the screen in 60 fps, as we have many objects on the screen and allow quite big zoom-out this is critical requirement.

But as we would like more to be added, there is going to be trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common things, and the second would work as cache, the pictures would be moved there from memory bitmap on demand. There are 2 problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow in allegro.
  2. It is not possible to work with video bitmap in other than the main thread in allegro, so it is practically not usable.

So here is the questions:

  • What would you recommend we do to solve this in our 2D game with lots of resources?

Edit: AddingEdit: Adding some requirements that we have in the game.

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs.
  • Most of the game is one continuous open world

Edit: I made some measurements.

The test consisted of drawing 10 000 sprites in a batch for sizes from 1X1 to 300X300 several times for every configuration. I did the tests on the Nvidia Geforce GTX 760.

  • Video bitmap to video bitmap drawing took 0.1us per sprite when the source bitmap wasn't changing between individual bitmaps (atlas variant), the size didn't matter
  • Video bitmap to video bitmap drawing, while the source bitmap was switched between drawings (no atlas variant), took 0.56us per sprite, the size didn't matter either.
  • Memory bitmap to video bitmap drawing was really suspicious. Size from 1x1 to 200X200 took 0.3us per bitmap, so not so horribly slow. For larger sizes, the time started to raise very dramatically (9us for 201X201 to 3116us for 291X291).

Conclusion. Using atlas increases the performance by factor greater than 5. If I had 10ms for the rendering, with atlas I'm limited to 100 000 sprites per frame, without it the limit of 20 000 sprites would problematic.

I was also trying to find a way to test the bitmap compression and 1bpp bitmap format for shadows, but I was unable to find a way to do this in allegro.

We are developing 2d game (Factorio) in allegro C/C++ and we are facing the problem with increasing video memory requirements as the game content increases.

What we currently do is, that we gather all the info about pictures that are going to be used first, crop all these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and the size of those depends on the system limitations, currently it is usually 2 pictures up to 8192X8192, so they require more than 256Mb and less than 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands pictures on the screen in 60 fps, as we have many objects on the screen and allow quite big zoom-out this is critical requirement.

But as we would like more to be added, there is going to be trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common things, and the second would work as cache, the pictures would be moved there from memory bitmap on demand. There are 2 problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow in allegro.
  2. It is not possible to work with video bitmap in other than the main thread in allegro, so it is practically not usable.

So here is the questions:

  • What would you recommend we do to solve this in our 2D game with lots of resources?

Edit: Adding some requirements that we have in the game.

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs.
  • Most of the game is one continuous open world

We are developing 2d game (Factorio) in allegro C/C++ and we are facing the problem with increasing video memory requirements as the game content increases.

What we currently do is, that we gather all the info about pictures that are going to be used first, crop all these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and the size of those depends on the system limitations, currently it is usually 2 pictures up to 8192X8192, so they require more than 256Mb and less than 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands pictures on the screen in 60 fps, as we have many objects on the screen and allow quite big zoom-out this is critical requirement.

But as we would like more to be added, there is going to be trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common things, and the second would work as cache, the pictures would be moved there from memory bitmap on demand. There are 2 problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow in allegro.
  2. It is not possible to work with video bitmap in other than the main thread in allegro, so it is practically not usable.

So here is the questions:

  • What would you recommend we do to solve this in our 2D game with lots of resources?

Edit: Adding some requirements that we have in the game.

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs.
  • Most of the game is one continuous open world

Edit: I made some measurements.

The test consisted of drawing 10 000 sprites in a batch for sizes from 1X1 to 300X300 several times for every configuration. I did the tests on the Nvidia Geforce GTX 760.

  • Video bitmap to video bitmap drawing took 0.1us per sprite when the source bitmap wasn't changing between individual bitmaps (atlas variant), the size didn't matter
  • Video bitmap to video bitmap drawing, while the source bitmap was switched between drawings (no atlas variant), took 0.56us per sprite, the size didn't matter either.
  • Memory bitmap to video bitmap drawing was really suspicious. Size from 1x1 to 200X200 took 0.3us per bitmap, so not so horribly slow. For larger sizes, the time started to raise very dramatically (9us for 201X201 to 3116us for 291X291).

Conclusion. Using atlas increases the performance by factor greater than 5. If I had 10ms for the rendering, with atlas I'm limited to 100 000 sprites per frame, without it the limit of 20 000 sprites would problematic.

I was also trying to find a way to test the bitmap compression and 1bpp bitmap format for shadows, but I was unable to find a way to do this in allegro.

4 deleted 63 characters in body
source | link

We are developing 2d game (Factorio) in allegro C/C++ and we are facing the problem with increasing video memory requirements as the game content increases.

What we currently do is, that we gather all the info about pictures that are going to be used first, crop all these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and the size of those depends on the system limitations, currently it is usually 2 pictures up to 8192X8192, so they require more than 256Mb and less than 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands pictures on the screen in 60 fps, as we have many objects on the screen and allow quite big zoom-out this is critical requirement.

But as we would like more to be added, there is going to be trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common things, and the second would work as cache, the pictures would be moved there from memory bitmap on demand. There are 2 problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow in allegro.
  2. It is not possible to work with video bitmap in other than the main thread in allegro, so it is practically not usable.

So here areis the questions:

  • What is the common waywould you recommend we do to solve this in 2d computer gamesour 2D game with lotlots of resources, like BG, Fallout etc?
  • What would you recommend we do?

Edit: Adding some requirements that we have in the game.

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs.
  • Most of the game is one continuous open world

We are developing 2d game (Factorio) in allegro C/C++ and we are facing the problem with increasing video memory requirements as the game content increases.

What we currently do is, that we gather all the info about pictures that are going to be used first, crop all these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and the size of those depends on the system limitations, currently it is usually 2 pictures up to 8192X8192, so they require more than 256Mb and less than 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands pictures on the screen in 60 fps, as we have many objects on the screen and allow quite big zoom-out this is critical requirement.

But as we would like more to be added, there is going to be trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common things, and the second would work as cache, the pictures would be moved there from memory bitmap on demand. There are 2 problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow in allegro.
  2. It is not possible to work with video bitmap in other than the main thread in allegro, so it is practically not usable.

So here are the questions:

  • What is the common way to solve this in 2d computer games with lot of resources, like BG, Fallout etc?
  • What would you recommend we do?

Edit: Adding some requirements that we have in the game.

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs.
  • Most of the game is one continuous open world

We are developing 2d game (Factorio) in allegro C/C++ and we are facing the problem with increasing video memory requirements as the game content increases.

What we currently do is, that we gather all the info about pictures that are going to be used first, crop all these images as much as possible and organize them into big atlases as tightly as possible. These atlases are stored in video memory and the size of those depends on the system limitations, currently it is usually 2 pictures up to 8192X8192, so they require more than 256Mb and less than 512Mb video memory.

This system works pretty good for us, as with some custom optimisations and splitting the render and update thread we are able to draw tens of thousands pictures on the screen in 60 fps, as we have many objects on the screen and allow quite big zoom-out this is critical requirement.

But as we would like more to be added, there is going to be trouble with the video memory amount requirements, so this system can't possibly hold.

One of the things we wanted to try is to have one atlas with the most common things, and the second would work as cache, the pictures would be moved there from memory bitmap on demand. There are 2 problems with this approach:

  1. The drawing from memory bitmap to video bitmap is painfully slow in allegro.
  2. It is not possible to work with video bitmap in other than the main thread in allegro, so it is practically not usable.

So here is the questions:

  • What would you recommend we do to solve this in our 2D game with lots of resources?

Edit: Adding some requirements that we have in the game.

  • The game must be determistic, so the performance issues/loading times can never alter the game state.
  • The game is realtime and soon to be multiplayer as well, so we need to avoid even smallest the stutters at all costs.
  • Most of the game is one continuous open world
3 added 360 characters in body
source | link
    Notice added Draw attention by Marwin
    Bounty Started worth 100 reputation by Marwin
2 deleted 244 characters in body
source | link
    Tweeted twitter.com/#!/StackGameDev/status/455120682003611648
1
source | link