MightyPirates
VRAM Is that how it was intended, or what?
I allocated an 80x25 buffer, which came out to 2000 bytes in VRAM. However, I filled it with characters and a white background, but didn’t notice any difference in the data usage. I thought that my text stored in the buffer would increase the size. For example, the character could be Russian… or even English, it doesn’t matter — according to my calculations it should have been 2132 bytes, but it returned 2000 bytes. I’m puzzled — where does the memory for the characters actually go? Into RAM instead of VRAM?
local address_module = component.list
local link = component.proxy
local module_screen = address_module("screen")()
local module_gpu = address_module("gpu")()
if not module_screen then error("Not found monitor") end
if not module_gpu then error("Not found gpu") end
local gpu = link(module_gpu)
local screenW, screenH = 80, 25
local BG = 0x000000
local FG = 0xFFFFFF
local BAR_FG = 0x00FF00
local BAR_BG = 0x555555
local vbuf = gpu.allocateBuffer(screenW, screenH)
gpu.setActiveBuffer(vbuf)
gpu.setForeground(FG)
gpu.setBackground(BG)
gpu.fill(1,1,screenW,screenH," ")
local function bufText(x, y, str, fg, bg)
if fg then gpu.setForeground(fg) end
if bg then gpu.setBackground(bg) end
gpu.set(x, y, str)
end
local function bufBar(x, y, w, ratio)
local fill = math.floor(w * ratio + 0.5)
if fill > 0 then
gpu.setForeground(BAR_FG)
gpu.setBackground(BG)
gpu.set(x, y, string.rep("#", fill))
end
if w - fill > 0 then
gpu.setForeground(BAR_BG)
gpu.setBackground(BG)
gpu.set(x + fill, y, string.rep(".", w - fill))
end
end
bufText(2, 2, "GPU_API BIOS DEMO", FG)
local interval = 0.5
local lastTime = computer.uptime()
while true do
local curTime = computer.uptime()
if curTime - lastTime >= interval then
lastTime = curTime
local totalRAM = computer.totalMemory()
local freeRAM = computer.freeMemory()
local usedRAM = totalRAM - freeRAM
local ramRatio = usedRAM / totalRAM
local totalVRAM = gpu.totalMemory()
local freeVRAM = gpu.freeMemory()
local usedVRAM = totalVRAM - freeVRAM
local vramRatio = usedVRAM / totalVRAM
bufText(2, 4, string.format("RAM: %d/%d KB", usedRAM, totalRAM))
bufBar(2, 5, screenW-4, ramRatio)
bufText(2, 7, string.format("VRAM: %d/%d KB", usedVRAM, totalVRAM))
bufBar(2, 8, screenW-4, vramRatio)
bufText(2, 10 , string.format("Uptime: %.1f s", curTime))
gpu.bitblt(0, 1, 1, screenW, screenH, vbuf, 1, 1)
end
computer.pullSignal(0.05)
end
By the way, an idea: you could add the ability to write numbers to VRAM — just integers and floating-point numbers. That would be really fun to play around with (:
I think it's to simplify the VRAM usage calculations, and in the real world a character would also have palette/color data attached to it, making the usage at least quadruple. The usage shown (just like the RAM usage on 64 bit JVMs) is only a simplistic estimation that actually makes hardware constraints without complexifying the mod too much (imagine having to deal with address spaces and such, I already had to do this while making a program in assembly, it was horrible)
it's very likely that when you edit the VRAM Buffer you edit the memory region that it has already allocated basicly how "VRAM Buffers" work in real computers as the entire allocation is already the entire "screen" you have requested (i have no idea how to explain this but i think you get the point) oh also i think that we should be able to have a call that will be able to change the entire buffer in one call (oversimplification: like doing variable = "XYZ" instead of adding every letter to the variable at once" because we wouldn't have to use thousents setForeground/setBackground/set calls to update the screen and slow down everything dramaticly
it's very likely that when you edit the VRAM Buffer you edit the memory region that it has already allocated basicly how "VRAM Buffers" work in real computers as the entire allocation is already the entire "screen" you have requested (i have no idea how to explain this but i think you get the point) oh also i think that we should be able to have a call that will be able to change the entire buffer in one call (oversimplification: like doing variable = "XYZ" instead of adding every letter to the variable at once" because we wouldn't have to use thousents setForeground/setBackground/set calls to update the screen and slow down everything dramaticly
I've computed that for an 80x25 display the amount of memory needed assuming 1 character = 1 byte is exactly 2000 bytes. If your theory was true then the buffer would be 3-6 times bigger (4000 bytes to store UTF8 characters + 2000-4000 bytes to store color informations depending on the color depth)
it's very likely that when you edit the VRAM Buffer you edit the memory region that it has already allocated basicly how "VRAM Buffers" work in real computers as the entire allocation is already the entire "screen" you have requested (i have no idea how to explain this but i think you get the point) oh also i think that we should be able to have a call that will be able to change the entire buffer in one call (oversimplification: like doing variable = "XYZ" instead of adding every letter to the variable at once" because we wouldn't have to use thousents setForeground/setBackground/set calls to update the screen and slow down everything dramaticly
I've computed that for an 80x25 display the amount of memory needed assuming 1 character = 1 byte is exactly 2000 bytes. If your theory was true then the buffer would be 3-6 times bigger (4000 bytes to store UTF8 characters + 2000-4000 bytes to store color informations depending on the color depth)
That's true but maybe they were just lazy when making VRAM buffers and just calculated the memory they needed to allocate by assuming that each byte was a character and it's color information (which honestly it's nice that they did that because of how RAM limited we are)