rozniak / rzxe Goto Github PK

Originally filed under Junkbot before this repo was split out.

When using the ISpriteBatch.Draw methods, drawing a sprite with DrawMode.Tiled results in garbage when the window is scaled outside of native res.

Could easily be fixed by using the native res as a uniform for calculations or something like that.

Just working on Junkbot and it has some test code in it that supports animations. In my opinion the animation supporting code should be in the engine, and the data supplied by the game itself.

Essentially, migrate and tidy up game-agnostic animation code that can go in the engine from Junkbot.

The engine should be able to draw text from a font as a resource that can be loaded in. For now this can just be a bitmap sprite font in the current atlas.

Kinda bored of implementing the same stuff in Dispose with bool disposing etc. would like a base class for some of this.

A lot of games use different colours within the same string of text - right now rzxe only has one single colour input into ISpriteBatch.DrawString and ISubSpriteBatch.DrawString.

Suggest that the Color color parameter becomes Color defaultColor, and that the drawing methods maintain what the current colour is when drawing characters - said colour can be changed via special character sequences in the string.

Essentially code like the following should be able to exist:

sb.DrawString(
    $"Press {TextColor.Input}SPACE{TextColor.Reset} to begin.",
    myFont,
    myPosition,
    Color.Black
);

(in the example, TextColor constants are of string type with special character sequences to change the colour of the text when parsed by the text renderer)

Rzxe only crudely supports drawing sprites straight from an atlas. Support should be added to give additional context about the kinds of things that can be drawn by the atlas, notably 'border-boxes' and 'fonts'.

In this sense, an atlas file should contain information for this kind of metadata - I call them 'resources':

• Border-boxes should reference 9 sprites used to draw a box with a border (4 corners, 4 sides, 1 body), possibly metadata about stretching/tiling the sides/body
• Fonts should contain references to sprites for each character, metadata regarding kerning and character/line spacing

This has been started in dev-packer-assets, I have mainly been working on a single dialog for this (to do sprite mappings) though will need to think of a neat way to include the type-specific metadata properties.

As rzxe was/is developed alongside Junkbot, it originally lived in the same repo and wasn't entirely separate like it is now. There is a direct hard coded reference to Junkbot in the window title still:
https://github.com/rozniak/rzxe/blob/dev/src/lib/Rzxe/Windowing/Implementations/GlfwFx/GlfwWindowManager.cs#L121

Obviously this needs to be fixed, the window title needs to be set by the game (at least in some capacity anyway!)

As per title - the mouse input in UxShell does not take into consideration the window scaling. If you resize the window, the hit tests will still take place as if the window is at normal size.

Mentioned by my good friend @paulsapps this loop could be simplified into a foreach per line if IFont expose a function for measuring a single line of a string:
https://github.com/rozniak/rzxe/blob/dev/src/lib/Rzxe/Windowing/Implementations/GlfwFx/GLSubSpriteBatch.cs#L488

Such a function actually already exists in the GL implementation, which is the only available renderer implementation at the moment:
https://github.com/rozniak/rzxe/blob/dev/src/lib/Rzxe/Windowing/Implementations/GlfwFx/GLSpriteFont.cs#L199

Could expose this as IFont.MeasureSingleLine or something, and make use of it that way - the code in sub-batch doesn't actually use anything specific in StringMetrics, only SingleLineStringMetrics.

There is currently no support for audio in rzxe at the moment. I haven't written any audio code before so it might take a bit of fiddling to get something going.

I believe there is some OpenAL stuff in Pencil.Gaming however ideally this should be abstracted similar to the graphics subsystem. I'll probably have to do some test work to play around with it and see how things can be abstracted and implemented - it almost certainly won't be perfect but there's always something more to learn.

There is some kind of latency going on when you drag the GLFW window around - it lags behind then catches up with the mouse. This also causes noticeable stutter on other applications, I noticed Discord voice chat/streams stutter like mad when dragging the window.

This occurs on Linux, under an X window environment... haven't checked Windows. It might be an X thing...

I think I mostly wrote things in a bit of a rush initially - I would like to run through the codebase and make sure it conforms to my standards. This includes adding Intellisense documentation on things - right now there is none as far as I can see. Idea being that this should make it easier to get to grips with the source again.

There needs to be a mechanism for creating an ISpriteBatch that persists. Currently the APIs only allow creation of a new sprite batch, all the drawing work / calculations done, committed to the renderer, then destroyed each frame.

For things that are static, it should be possible to create an ISpriteBatch with all vertices and whatnot precalculated, so that Finish() can be called each frame.

There is rendering corruption when a change to a draw instruction results in a change in its vertex count. The surrounding code handles changes as they are in place (splicing in the existing buffer size) resulting in an overrun.

If the vertex count of a draw instruction has changed then the entire buffer will have to be regenerated/resized to account for this.

Need to implement the ability to tint sprites via alpha compositing in the fragment shader. This is especially important for fonts so that font colour can be chosen.

Straight forward - need to add an attribute to pass to the fragment shader to set the final alpha when drawing a sprite.

Need to add AppVeyor CI for this repository.

The bin packer tool is a bit 'dumb' at the moment, it simply bin packs the sprites into the atlas - it has no knowledge of resources on the atlas.

Should implement the ability to consume JSON for border box and font info - and for fonts, detect sprites that belong to a font and handle special character names like:

font_default_comma map to font_default_,

Necessary to support dialogs/windows - should have a UxContainer class or something.

PointExtensions is pretty well done I think, however the SizeExtensions and RectangleExtensions classes are not. Would be good to implement things like .Add() and .Subtract() to these so they're available just like they are for Point/PointF.

The windowing implementation right now has no formal directive on how to scale the viewport. The only window manager right now is GLFW and it simply stretches the viewport at the moment.

Maintaining aspect ratio would be a good feature to have and should be straight forward enough to implement in the vertex shader.

There are enums for gamepads (based on the GLFW ones atm) in ControlInput, but there's no API in InputEvents to report gamepad inputs, and as a result there's also no support in GlfwWindowManager.

Currently to build rzxe you must also include the Pencil.Gaming project because the GLFW renderer resides in the main rzxe project file.

Renderer implementations should live in their own projects and compile to their own libraries, right now there's only the GLFW implementation so it should be moved out.

InputEvents doesn't contain any state info for the last position of the mouse - likely a little oversight.

Would like to replace SortedList2 with a collection class that is capable of having hooked methods to support this + add/remove events and such.

There is currently no support for drawing block colour shapes in a sprite batch - only sprites (and the related things that use sprites).

Suggest adding a DrawMode for block colour drawing, and a 'shape' draw instruction.

Common feature for drawing UI elements is to have a kind of 'border box'. A button for instance would be made out of 9 segments - 1 centre piece for the body, and 8 surrounding cells for the borders.

This should be a resource that makes use of sprites on the atlas.

At the moment sprite batches are essentially immutable aside from appending on new drawing 'steps' (in the form of VBOs for OpenGL).

Functions inside ISubSpriteBatch should not immediately compose anything, they should create objects that represent the steps, and there should be ways to reference and therefor edit/delete steps in the batch.

The sprite batch should be 'dirtied' if these steps change, and composed (if necessary) when Finish() is called.

I need to repack stuff and the bin packer tool has fallen behind - it doesn't really need to be a GUI right this second so I will replace it with a CLI tool for now so it is quicker to keep up-to-date when any atlas code changes.

There is a requirement that multiple separate sprites (on the same atlas) be used during individual frames of an animation. This issue to track progress on that feature.

Shouldn't be too hard, just extending the JSON format and ActorAnimationFrame.

In future rzxe will need to support networking - this shouldn't be too difficult, I've written networked applications before and have a fairly good idea on how to draw up some abstractions and whatnot to use in the engine.

Right now this isn't a priority as getting the audio/visual stuff is of course the main focus at the moment. I expect this will be worked on at some point in the future when I resume work on RozWorld as I would like to make it utilise rzxe, and thus networking needs to be present in rzxe.

Currently inputs are taken in the form of strings such as:
vk.a
vk.s
mb.left
mb.middle

It would be better to have this in a kind of enum that covers our inputs, perhaps along the lines of:
ControlInput.KeyA
ControlInput.KeyS
ControlInput.Mouse0
ControlInput.Mouse3

This would make the code less error prone due to potential typos in strings (plus strings just seem like a dirty way of doing this kind of thing).

Project repo needs a README.MD, I started a new branch dev-readme for this and was working on a SVG format logo. The usual description and whatnot that you'd find in a README.MD needs doing.

The game may need to communicate back to rzxe for certain things such as retrieving information about the renderer (such as the current viewport size) and things along those lines. As such there should be an interface provided by rzxe that's injected into the game at initialization to access this stuff.

The OnClick(), OnMouseDown(), and OnMouseUp() event triggers in UxComponent are not set up to receive any information about the mouse. Button and position data should be forwarded so additional hit tests can be done within the overridden methods and so that they can fire an event containing this data.