Surfaces

[Exmirai]

Since OpenJK have modular renderer i think i can suggest following: what about creating class "Surface" which will replace/extend regular 2d draw system. We can draw text, rectangles, images, paint them ( may be even postprocess ( hello rend2 :> ) )

In ui/cgame that can look like:

Surface sufrace(640, 480);
surface.paint( Color.Red );
surface.drawrectangle( 100, 100, 10, 10, Color.Green) 
surface.drawtext( 200, 200, "Hello World")
surface.transform() -- whatever transformation

surface.render() -- queue
OR
trap->RenderSurface(surface) 

would be good :>

 

[Raz0r]

It would make more sense to redesign and expose more of the renderer than tacking on more abstractions that don't really fit.

[ensiform]

I don't really see the benefit to this at the present time especially without major redesign. The original renderer wouldn't see any improvements using this type of change either.

[eezstreet]

It would break compatibility. I'd rather see a widget-based system with only one call to start drawing an item and one call to stop drawing an item. This would be a significant improvement.

[ensiform]

Text, rectangles, all supported already in cgame and ui...

 

@@eezstreet unfortunately what you've suggested would be compat breaking too.  As drawing must happen every frame.

[eezstreet]

Text, rectangles, all supported already in cgame and ui...

 

@@eezstreet unfortunately what you've suggested would be compat breaking too.  As drawing must happen every frame.

Naturally. I figured that if we were going to break compat, might as well improve efficiency.

[Exmirai]

No. it will not break compat, why? we're could just add class in renderer/engine and link them. In cgame/ui we can just add RenderSurface() to trap->ext and there are wouldn't be any compat issues 

[ensiform]

JA++ is the only mod that is C++ anyway.  Plus the GetModuleAPI is extern "C" so it must use C structures or void* afaik.  Maybe your method wouldn't necessarily break compat but tbh I don't see it being something we need.

[Futuza]

JKG is sorta in C++ just FYI.

 

I think a new way of drawing ui elements might be nice, but I'm not sure it'd necessarily belong in openjk...maybe it'd be best to have it as a openjk add-on or something instead.

[ensiform]

Yeah, this is a suggestion for OJK though not JKG specific.