Quantcast

Results 1 to 4 of 4

Thread: there a video buffer calculator?

  1. #1
    Nameless One vexatious's Avatar
    Join Date
    Oct 2014
    Posts
    92
    Rep Power
    6

    32X there a video buffer calculator?

    Looking for a video buffer calculator. Is there such a thing?

    Basically I'm trying to calculate a buffer to framebuffer without 3d.

    My target screen space is 352x240@15-bit color (32768 colors) and 60 frames per' second, and 180 degrees (or 8 directions: top, down, left, right, top-left, top-right, down-left, and down-right), how many megabytes per second would this translate to? My example would be 2d tile layers: maybe 4 layers 1/8th vertical screen size, fullscreen tile, six random 32x32 sprites on top @ 15 frames animation, and random animation (4 frames on each tile).

    How many megabytes would this translate to? There such a tool? There a common way to come up with this?

    Thanks for the feedback.

  2. #2
    Raging in the Streets Sik's Avatar
    Join Date
    Jan 2011
    Posts
    3,535
    Rep Power
    64

    Default

    @_@

    What you want to do depends entirely on both the hardware in question and how the underlying engine stores data (you probably won't store pixels as-is, you'll build a map out of tiles that may be repeated). There's a lot more information needed here.

    EDIT: although if what you want is just a framebuffer to draw onto… It's width × height × color depth (so in your case 352 × 240 × 2 bytes = 168960 bytes). That's per buffer, so e.g. if you do double buffering multiply that by two. Anything else is not relevant to the framebuffer itself, sprites and such take up memory but that's on their own (incidentally, the same calculation would be used in that case, for every bitmap you have).

  3. #3
    Nameless One vexatious's Avatar
    Join Date
    Oct 2014
    Posts
    92
    Rep Power
    6

    Default

    Thank you for the response.

    Basically I don't want to waste my time without a tool. Ironically if I don't have the tool I have to make it, but if I proceed doing things without the tool it'll be a big waste.

    Should've mentioned I'm basically needing profiles for different targets (or capacities) and a way to apply those profiles, so it's basically similar to a debugger but It's for graphic design and editing. Similar to a bitrate calculator for encoding movies (maybe I've done too much video editing ) but in this case it's for applying a large layout (or should I say map?) of say 1024x1024 to different targets; could be 15-bit or 8-bit color and smaller screen spaces etc.

    Obviously not every rom (or ram) source can buffer into video ram fast enough depending on speed of rom-ram and implementation vs content. To make things even more confusing, the term buffer doesn't seem used properly. For example, video ram should be called cache since it seems to be always faster than rom-ram, so why reference video ram as buffer? If it's not confusing enough, buffering works the same way as cache except it serves a different purpose; buffer is a data backup in case of inconsistency whereas cache makes things happen as fast as possible. Why is there video terms like double-buffering or triple-buffering (sheesh )? Unless things are too slow and prone to errors, it doesn't make sense to double-buffer from video ram plus it seems to work against itself; and this should be called triple buffering since there's rom-ram buffering into dual framebuffers (assuming this is used).

    Either way I might buffer as fast as possible, or with more consistency (multiple buffers). Programs like irfanview and GIMP don't have the tool or suite of tools I need to make multiple application profiles. Also, I'd probably be using a clean hack (no data; only functions and pointers with changes), though a clean rom from scratch might be bootstrapped or assembled (however u want to call it).


    I'm surprised there's no program on internet for Windows for Workgroups 3.1. Wasn't WFW 3.1 and MacOS primarily used for assembling games? I've only seen references to Sonic Xtreme and Windows 95 but they're very vague and no mention on how it assembles content (or the type of content).

    Thank you.

    EDIT
    Don't post from smartphones LOL. Just re-did entire post after accidentally deleting when trying to edit.

  4. #4
    Outrunner Eep386's Avatar
    Join Date
    Sep 2014
    Location
    Not far from Sacramento
    Posts
    521
    Rep Power
    18

    Default

    Quote Originally Posted by vexatious
    Basically I don't want to waste my time without a tool. Ironically if I don't have the tool I have to make it, but if I proceed doing things without the tool it'll be a big waste.
    The best tool for this is an ordinary calculator, I'd argue.
    Since 8 bits = 1 byte, multiples of 8 bits can be expressed as Bit size divided by 8, so 32 bits divided by 8 = 4 bytes.
    To calculate buffer size for an 8-bit framebuffer, you simply multiply Horizontal pixel size by Vertical pixel size. 320 x 200 x (8 / 8 = 1) = 64000 bytes. For 16 bits, this becomes 320 x 200 x (16 / 8 = 2) = 128000 bytes.
    For odd bit counts and less than 8 bits, you still multiply by (bit count) divided by 8; eg. 320 x 200 = 64000 x (4 / 8 = 0.5) = 32000 bytes. 15-bit, 320 x 200 = 64000 x (15 / 8 = 1.875) = 120000 bytes (unless the graphics controller treats 15-bit buffers as 16-bit, as may be the case with some crusty old packed-pixel framebuffers - in those cases you'll have to treat them as 16-bit counts).

    For double buffering, you'd double that result further. Triple buffering, you'd triple it.

    Quote Originally Posted by vexatious
    Obviously not every rom (or ram) source can buffer into video ram fast enough depending on speed of rom-ram and implementation vs content. To make things even more confusing, the term buffer doesn't seem used properly. For example, video ram should be called cache since it seems to be always faster than rom-ram, so why reference video ram as buffer? If it's not confusing enough, buffering works the same way as cache except it serves a different purpose; buffer is a data backup in case of inconsistency whereas cache makes things happen as fast as possible.
    It's called a buffer because oftentimes that's exactly what it is, a buffer to hold graphical data. It differs in purpose from a cache, which is to hold frequently-reused data close to the processor in a special, very fast type of RAM, typically static RAM, but sometimes self-refreshing DRAM (so-called 'pseudo SRAM') if it's running at a wider internal data bus or higher clock speed than the external memory. This way, commonly reused data won't have to be fetched from a slower RAM space. Video buffer, conversely, is just where the stuff that's meant to be displayed (or put together to be displayed later) is stored.
    We could make entire video buffer memories out of SRAM for maximum possible speed, but SRAM tends to be vastly more power- and transistor-hungry than DRAM, so it would be prohibitively expensive and hot-running in the elephantine capacities we've come to expect in modern video cards. DRAM that's embedded into a video chip is sometimes called eDRAM, or embedded DRAM.

    Quote Originally Posted by vexatious
    Why is there video terms like double-buffering or triple-buffering (sheesh )? Unless things are too slow and prone to errors, it doesn't make sense to double-buffer from video ram plus it seems to work against itself; and this should be called triple buffering since there's rom-ram buffering into dual framebuffers (assuming this is used).
    The big benefit of double/triple buffering is that it helps minimize ugly 'draw-in' and flickering artifacts while drawing moving scenes, by making sure that the CPU/GPU isn't writing to the same memory space the video controller is displaying. Double buffers have one 'visible' buffer which is shown onscreen, while the second 'work' buffer is being drawn up. Triple buffering is the same thing, but given a second 'work' buffer to additionally ensure that, in case the CPU/GPU has to take more time than usual to render one frame for whatever reason, there's still an extra frame of video data available to cover minor hiccups in frame rate with a lower risk of draw-in and flicker artifacts. (The CPU/GPU running out of time to finish one frame before showing it is one potential cause of 'screen tear' artifacts, but is not the sole cause of all screen tearing as a lack of proper frame synchronization to the monitor can also cause massive tear artifacts even though there's plenty of time to efficiently finish each successive frame.)

    It's not necessarily any faster than just drawing to a single screen page repeatedly, but it's not necessarily any slower either if done in an efficient manner, unless said target hardware or screen mode doesn't really support it, in which case the CPU or GPU will have to transfer a large amount of data from one space of memory into the 'visible' area of memory. This can be especially slow if it has to transfer it over a much slower bus in the middle. Modern GPUs (and indeed many legacy graphic chips) will handle double and triple buffering internally, staying within their very fast dedicated memory spaces so that the performance hit of multiple buffering is usually negligible, at the cost of potentially having less memory available for screen resolution or graphical elements. (Hence the rise of video cards with ridiculously huge on-board memories, like 12GB.)

    Edit: I should mention, that triple buffering does carry the potential risk of imposing additional latency in screen updates, as the update 'cycle' can be more than a frame behind the 'drawn' frame. Again, well-written display code will minimize or avoid this, but unfortunately we don't live in a perfect world where code is always flawless...
    Last edited by Eep386; 10-18-2018 at 03:38 AM. Reason: I sHouLD mention

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •