Topic: In case you had not heard.

[James]

OK.

This is really starting to blow my mind.....

I guess my problem is that I'm sort-of half-way between two worlds here...

The way I wrote LaserBoy to work with SDL was to only use SDL for the most primitive features; an area of screen to copy a bitmap to and a way to read hits from the keyboard.

I've got my own bitmap class to render stuff in for display, so all I have to do is copy from a pointer inside of that to the pointer to the screen area that SDL provides.

I also have my own bitmapped font so I can put text on the display.

This is something that is a nice generic concept. It is possible to put text into any bitmapped area of the screen, regardless of what platform development environment I use.

BUT....... That was sort of a concession for the sake of simplicity. If I plan to use a more widget oriented development environment, I won't have much of a need to put text in the display.

So, where does that put things?

I have a bitmap (actually a set to include wiping the screen clean and putting a background image into the display).

I have a bitmapped font.

I have a whole menu system that knows how to write into the bitmap with no knowledge of any development environment.

On the other hand... I have a keyboard event loop that gives me an SDL specific enumerated type every time a key is hit. So I can not really put an interpret_key(SDL_Key) function anywhere but inside the outermost SDL GUI class.

If I do this right, I should be able to convert it back to my old EZFB Linux frame buffer API by just switching out the top level class.

I should also be able to swap in a new GUI layer that makes no use of text in the bitmap display at all.

I'm so confused!

I think I'm going to make a middle class between LaserBoy_space and the outermost controlling GUI class.

It will be the LaserBoy_text_display class, that will inherit LaserBoy_space and provide text in the display, if needed.

James. 

PS. Maybe the "middle class" is actually making a comeback!

[drlava]

With FLTK you don't need to use bitmaps at all. 
Change the menu system to write to a text handler, and then that text handler can write the bitmap (in the transition period) or once FLTK takes over, it will write text to the appropriate GUI area.  Same thing with screen updates.  pass pointers and commands to a handler, and let the screen update handler either paint a bitmap as now, or with the new code it will draw using the FLTK widgets.  They both need the same info - what frame, frame pointer, cursor posn, etc.  The difference is that the handlers are only given the info they need, no assumptions about how they will accomplish the display are made. 

for the keyboard entry, yeah keep that in a loop for now.

[James]

WOW! Your're ON. 

I wish I could easily show you what I have right now.

I know I don't "need" my bitmap class, but that is just a chunk of mem with a pointer and some specs. That should be universal.

Change the menu system to write to a text handler, and then that text handler can write the bitmap (in the transition period)

Huh

As a C/C++ programmer of many years, I always know to ask "What am I? What do I know? What do I need to know?"

James. 

PS. The good news is I haven't been this wrapped up in the code for a long time! 

[James]

Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.......................

[drlava]

Sorry for coming off a bit strong.  Correct me at any time

I have a whole menu system that knows how to write into the bitmap with no knowledge of any development environment.

Change the menu system to write to a text handler, and then that text handler can write the bitmap (in the transition period) or once FLTK takes over, it will write text to the appropriate GUI area.

\Huh Huh

What I mean is, instead of a menu system that knows how to write into a bitmap, the menu system maybe should pass info to some other code that can either 1) write it to a bitmap in this interim time, or 2) when the FLTK code is written, handle it in its own way. 

What I was thinking is that while the FLTK code is built up, the menu system could be contained in a display box similar to the way it is now.  Once the GUI is finished, the display box could be optionally hidden for those who want to access all of the operations with a mouse only, or left visible for people who like working with the keyboard menus.

[James]

Sorry for coming off a bit strong.  Correct me at any time

Not at all! I need as many good ideas as I can get right now!

I do want to keep the keyboard short-cuts AND have mouse menus.

I worked on it quite a bit last night with the idea of the LaserBoy_text_display class in between the LaserBoy_space class and the LaserBoy_SDL_GUI class


LaserBoy_text_display is-a LaserBoy_space

LaserBoy_SDL_GUI has-a LaserBoy_text_display

I keep thinking it would be good to have a pointer to the top level GUI class, known to the LaserBoy_space object. That way I could define a generic GUI->refresh_display() function that would call upon SDL stuff. I could call this function from anywhere in the LaserBoy core. When I replace the top with FLTK, I just redefine the refresh_display() function with FLTK stuff.

James. 

[BlinkenLights]

ok so seperate out the error and info messages, including anything that shows up under the palette and at the top or bottom of the laserboy display. make them seperate from the menu texts. that way, later, we can point those text strings that are errors or info to other places.

[BlinkenLights]

as a matter of fact.. just pull the ALL out and send data from the string handler to the bitmap thingy that draws the text.

that way the gui can access ALL those strings.

[James]

I think I am beginning to see the light at the end of the tunnel.

Everything compiles now, but I am getting linker errors. Most of those got sorted out in bugs in the Makefile that calls the linker after the compiler. Now I just have to fill in a couple of gaps in function definitions since I split some of the old function into as many as three new ones.

James. 

[James]

FIANNLY !!!

LaserBoy is BACK !!! 

I just saw that stupid smiling face for the first time since I busted it all up a few weeks ago!

I still need to sort a few things out, but IT WORKS !!!

James. 

[BlinkenLights]

[Lazerjock]

So when will we get to see the new LaserBoy?

[James]

Hopefully, very soon.

Don't get too excited; unless you like to look at code.

The running application should look exactly the same.

The big difference is in the reorganization of the code for future development.

James. 

[Lazerjock]

James I thought you were going to have a new fancy GUI.

[James]

It will! ..... in due time.

I just sorted everything out so that all of the calls into SDL.dll are all in the same, top-level object.

Now all I have to do is scrape of this object and replace it with something else.

James.