3rd `vbank` for internal use / performance tools /etc?

[joshgoebel]

I was just trying to figure out what hoops I'd need to jump thru to draw a nice system overlay on top of the users game... say if we wanted to show a histogram of CPU usage or frame counter or something... there didn't seem to be any great options since we don't have any drawing primitives for writing directly to the REAL 24-bit screen buffer. Then I realized we've already abstracted this almost too perfectly with VRAM banks.

I'm imagining something like the old WinAmp equalizer to let you see performance metrics for the last 60 seconds.

So could we just add a 3rd system (not accessible to cartridges) VBANK for system overlays? It would have it's own palette, we could use all the familiar TIC API for drawing to it from the C side... but only the C code would be able to switch to from/it. When doing blit we'd check if the 3rd vbank was accessed at all that frame (single check) and if so we'd draw it as a fixed overlay on top of all the user data, if not, nothing...

I'm actually imagining this wouldn't be very much new code at all since all the pieces are already in place... open to other suggestions for drawing system overlays, but this sounds pretty nice I think.

[nesbox]

I think it shouldn't be part of the core, we could create an additional instance of tic_mem somewhere inside the studio, draw metrics, and blit somewhere next to the blitCursor() function.

[joshgoebel]

it shouldn't be part of the core

Could you elaborate what that means exactly? I mean ok, if we want a separate data area (to not pollute the "core" "hardware" with a 3rd bank)... but if so I'd have to have a second tic_core as well... because I need both mem and core to use many of the existing draw calls. Remember that pesky issue I filed about how they are interchangeable? #1779. Plus we often need access to CLIP, which is not (currently) in tic_mem.

Also duplicating core or mem would (in the past) have duplicated our whole memory allotment (but not if RAM is a pointer). Just a side note. :-)

I think I imagined it would hang off of core.state where we hang other such internals:

• pause RAM
• "OS" input storage

All of these things are already sort of "outside" core hardware, are they not? They are more concerns of the TIC-80 studio/OS. I probably would have created a:

• core.state.vbank_overlay

or something... Also I think using vbank.id to track the state sort of makes sense unless you want a 2nd explicit status variable bool using_vbank_overlay or some such...

...thoughts?

[joshgoebel]

we could create an additional instance of tic_mem

Also, why do we need the whole memory though if all we need is 16kb of VRAM data?

[nesbox]

Studio/OS doesn't have access to the tic_core because it's designed for internal use only, they can communicate with each other using only the API language.

All of these things are already sort of "outside" core hardware, are they not?

Well, then we have to move pause RAM and etc to the studio level to match the design.

Another idea, you can use the existing tic_mem to draw the stats using the following steps:

• draw the studio
• call tic_core_blit()
• copy rendered screen buffer somewhere
• clear current VRAM using cls() api
• draw stats using API
• call tic_core_blit()
• combine rendered stats with rendered screen buffers

[joshgoebel]

Studio/OS

Wait, do you think of the studio as the OS? If so I'd think it could access all the internals, that's kind of what the OS layer does... but if studio is an "app" running on the TIC-80 "OS" then of course it should be much more limited. To me studio is orchestrating tasks, pausing tasks, resuming tasks, reseting tasks... it's literally driving the whole ship, making it very much appear to be the OS layer and main app combined.

I come from heavy OOP background, so when I look at relationships I look at the messages being passed, not just who has easy access to which data. If studio has the headers to call a tic_core_formatWholeDisk function it really doesn't matter whether it has access to the disk_sector struct or not, it's still behaving as an "OS" because of it's ability to call that function in the first place.

Another idea, you can use the existing tic_mem to draw the stats

Yeah I thought of that but it worded like a lot of effort. :-)

[nesbox]

Wait, do you think of the studio as the OS?

I don’t know, we need to decide, the studio has access to the file system and the network, while the core doesn't, after all, it looks more like an OS than an application, I think :) At the same time, I don't want to give access to the internals of the core, let there be a clear border here. Something like this.

[joshgoebel]

To me (just based on naming) the "studio" is the TIC-80 IDE... the graphical editors, etc... (technically I'd probably even separate out console)... in a world where TIC-80 was a tiny little OS-like engine I imagine you'd have separate processes for:

• console
• studio
• game
• menu (part of OS trappings)

after all, it looks more like an OS than an application

Well yeah, right now, but obviously there is a studio application here somewhere hidden in all that code. :-) So the question becomes whether it's easier to refactor the studio or OS parts out of studio. :-) I'll take another look and post more thoughts.

[joshgoebel]

Also seeing all those BUILD_EDITORS conditional defines makes me think "studio"... I feel like if you compile things without editors that you really don't have the "studio" anymore... so it would be nice if all those conditionals could just disappear once we separated the editors/studio from the OS pieces. Maybe that would be a fun thing to try, to rip all of those out into a separate file and see where that leaves us...

Then you have weird in-betweens like "export sfx" and "export music"... the code is in studio, but the console is the only way (that I know of) to trigger it... so one imagines a world where you say only compile the console... I'd still expect export to work, even without the studio... it's almost a "command line tool" for the build in OS/console more than a part of the visual "studio"/IDE experience...

[joshgoebel]

Any long term thoughts on SURF? I know we have issues asking for it to be "separate" from studio so people could pull it up on android, etc... browse games, etc... should we think about that long-term that surf has it's own BUILD flag and could exist without all the editors, etc?

[nesbox]

should we think about that long-term that surf has it's own BUILD flag

I think yes, why not if people want it :)