Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Console drawing library #26

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Conversation

c0de90e7
Copy link

phiren, these are the files needed, I did not add a MakeFile and I still have some doubts. Also, I did not add a sample... plus there is still some small glitch to fix.

Thank you...

@Parlane
Copy link
Member

Parlane commented Nov 15, 2010

Ok, so lets start with how and why it matches the criteria laid out at:

https://github.com/HACKERCHANNEL/PSL1GHT/wiki/Framebuffer-Console-Requirements

For each bolded heading list how your code meets the criteria. :)

@Parlane
Copy link
Member

Parlane commented Nov 15, 2010

Also for us joes at work, do you have screenshots of it in action? :)

@c0de90e7
Copy link
Author

It must not have any dependencies on psl1ght.

it has no dependencies, it was designed to be used by a debugger or alike, the only dependency is ram (framebuffer). It does use memset, malloc and free but no more dependencies than those...

No fixed font sizes.

It supports NxM fonts or better say gliphs, including cursormask, mousepointermask,... SlotWidth and SlotHeight are passed on initialization to CONSOLE_RENDER_Initialize() together with character/cursor/mousepointer gliph bitmaps, which must have SlotWidth/8 * SlotHeight bytes; If the SlotWidth is not a multiple of 8, then the bits need to be rightpadded ( example: 12x16 gliphs would use 2*16 bytes, where those 2 bytes would be 16 bits and leftmost 12 would be SlotWidth bits for each gliph line ).

Flexible console and render target(s).

It was written so that console logic and console rendering were decoupled, I can have multiple consoles to multiple renders; even video output is decoupled and we can render to different regions, diferent gliph sizes, 1 to N or N to M relations... you can see CONSOLE_VIDEO, CONSOLE_LOGIC and CONSOLE_RENDER are separated and you can independently use them and mix them as you like...

There is 3 separate """classes"""

CONSOLE_VIDEO < handles output buffer and creates a movable viewport of same or smaller size into it; it can be set to 1/2/4 byte per pixel in resolution and you can initialize as many as you want. Also, one can initialize multiple CONSOLE_VIDEO handles to a same backing output buffer ( maybe because you want to have 2 different viewports or logical windows ) or to different backing buffers ( double buffering or different texture outputs or whatever... )

CONSOLE_LOGIC < handles "blind" or aseptic console logic of NxM cols*rows; it just handles Attr+Char pairs per cell and has cursor and mousepointer handling; also tracks changes for a "get delta changes" functionality, useful for later drawing changes only ( optimization ). You can initialize and use as many handles as you want

CONSOLE_RENDER < handles the rendering of any CONSOLE_LOGIC to any CONSOLE_VIDEO; it takes the font+cursor+mousepointer gliph bitmaps, SlotWidth and SlotHeight, etc. All the "drawing" stuff. But the thing is that it doesnt take CONSOLE_VIDEO and CONSOLE_LOGIC in initialization time. So, later, you can do CONSOLE_RENDER_Render(ConsoleRenderHandle, ConsoleLogicHandle, ConsoleVideoHandle); passing any ConsoleLogic and any ConsoleVideo; so you can use the same ConsoleRenderHandle for many different viewports/outputs and for drawing different consoles independently etc.

Double buffering.

This actually comes with the previous one, using 1, 2, 3 or N CONSOLE_VIDEO handles, you can render to any number of outputs, in this case, being those outputs 2 or more framebuffers; but it could even be the same one, be offscreen textures, etc.

No global variables.

It has no global vars... each of those 3 """classes""" initializes a handle ( struct ) that holds the needed data

Transparency.

I have implemented configurable ( 0..15; textmode ) color for transparency; defaulted to 0 ( black ) but settable. I have made the rendering configurable by rendering flags; theres currently 3 flags:

  • transparency ON/OFF
  • dropshadow ON/OFF
  • use dropshadow over non transparent backgroud ON/OFF

Reading from the framebuffer.

Although originally it had framebuffer ( or better say output buffer ) reads to do Save/Restore functionality ( that I saw desirable, but maybe it doesnt make sense now... and is anyway doable externally ), its not there right now, so no buffer reading now.

Non-Scrolling text.
I do have a CONSOLE_MISC ( you can see it as CONSOLE "terminal" thing ) with very few functions to printf, scroll, etc.; but I didnt port it yet... I even have plans to do window managing, maybe with cursor/mousepointer integration and event system with callbacks... but right now, the only thing i can give on this subject is screen text printing and siiimple scroll...

This is going to be my next work; very simple scroll and a decent printf. There will be a CONSOLE_MISC or maybe called CONSOLE_TERMINAL or something like that that works over CONSOLE_LOGIC handles.

But id like to fix some small glitches first and discuss possible polishing changes you may suggest or other requirements or so...

Hoping this answers it...

Finally, here are some shots:

http://yfrog.com/03photo1mpj
http://yfrog.com/65photovqj
http://yfrog.com/jx3fndj
http://yfrog.com/e4m8xmj

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants