SketchyMaze/doodle
SketchyMaze/doodle
1
0
Fork 0
Code Issues 41 Pull Requests 1 Releases Wiki Activity
6713dd7bfc
doodle/balance/numbers.go

33 lines
611 B
Go
Raw Normal View History

Abstract Drawing Canvas into Reusable Widget The `level.Canvas` is a widget that holds onto its Palette and Grid and has interactions to allow scrolling and editing the grid using the swatches available on the palette. Thus all of the logic in the Editor Mode for drawing directly onto the root SDL surface are now handled inside a level.Canvas instance. The `level.Canvas` widget has the following properties: * Like any widget it has an X,Y position and a width/height. * It has a Scroll position to control which slice of its drawing will be visible inside its bounding box. * It supports levels having negative coordinates for their pixels. It doesn't care. The default Scroll position is (0,0) at the top left corner of the widget but you can scroll into the negatives and see the negative pixels. * Keyboard keys will scroll the viewport inside the canvas. * The canvas draws only the pixels that are visible inside its bounding box. This feature will eventually pave the way toward: * Doodads being dropped on top of your map, each Doodad being its own Canvas widget. * Using drawings as button icons for the user interface, as the Canvas is a normal widget.
2018-08-17 03:37:19 +00:00
package balance
// Numbers.
var (
Move Editor Canvas Into UI + UI Improvements * Increase the default window size from 800x600 to 1024x768. * Move the drawing canvas in EditorMode to inside the EditorUI where it can be better managed with the other widgets it shares the screen with. * Slightly fix Frame packing bug (with East orientation) that was causing right-aligned statusbar items to be partially cropped off-screen. Moved a couple statusbar labels in EditorMode to the right. * Add `Parent()` and `Adopt()` methods to widgets for when they're managed by containers like the Frame. * Add utility functions to UI toolkit for computing a widget's Absolute Position and Absolute Rect, by crawling all parent widgets and summing them up. * Add `lib/debugging` package with useful stack tracing utilities. * Add `make guitest` to launch the program into the GUI Test. The command line flag is: `doodle -guitest` * Console: add a `close` command which returns to the MainScene. * Initialize the font cache directory (~/.cache/doodle/fonts) but don't extract the fonts there yet.
2018-10-08 17:38:49 +00:00
// Window dimensions.
Width = 1024
Height = 768
Abstract Drawing Canvas into Reusable Widget The `level.Canvas` is a widget that holds onto its Palette and Grid and has interactions to allow scrolling and editing the grid using the swatches available on the palette. Thus all of the logic in the Editor Mode for drawing directly onto the root SDL surface are now handled inside a level.Canvas instance. The `level.Canvas` widget has the following properties: * Like any widget it has an X,Y position and a width/height. * It has a Scroll position to control which slice of its drawing will be visible inside its bounding box. * It supports levels having negative coordinates for their pixels. It doesn't care. The default Scroll position is (0,0) at the top left corner of the widget but you can scroll into the negatives and see the negative pixels. * Keyboard keys will scroll the viewport inside the canvas. * The canvas draws only the pixels that are visible inside its bounding box. This feature will eventually pave the way toward: * Doodads being dropped on top of your map, each Doodad being its own Canvas widget. * Using drawings as button icons for the user interface, as the Canvas is a normal widget.
2018-08-17 03:37:19 +00:00
// Speed to scroll a canvas with arrow keys in Edit Mode.
CanvasScrollSpeed int32 = 8
Implement Chunk System for Pixel Data Starts the implementation of the chunk-based pixel storage system for levels and drawings. Previously the levels had a Pixels structure which was just an array of X,Y and palette index triplets. The new chunk system divides the map up into square chunks, and lets each chunk manage its own memory layout. The "MapAccessor" layout is implemented first which is a map of X,Y coordinates to their Swatches (pointer to an index of the palette). When serialized the MapAccessor maps the "X,Y": "index" similarly to the old Pixels array. The object hierarchy for the chunk system is like: * Chunker: the manager of the chunks who keeps track of the ChunkSize and a map of "chunk coordinates" to the chunk in charge of it. * Chunk: a part of the drawing ChunkSize length square. A chunk has a Type (of how it stores its data, 0 being a map[Point]Swatch and 1 being a [][]Swatch 2D array), and the chunk has an Accessor which implements the underlying type. * Accessor: an interface for a Chunk to provide access to its pixels. * MapAccessor: a "sparse map" of coordinates to their Swatches. * GridAccessor: TBD, will be a "dense" 2D grid of Swatches. The JSON files are loaded in two passes: 1. The chunks only load their swatch indexes from disk. 2. With the palette also loaded, the chunks are "inflated" and linked to their swatch pointers. Misc changes: * The `level.Canvas` UI widget switches from the old Grid data type to being able to directly use a `level.Chunker` * The Chunker is a shared data type between the on-disk level format and the actual renderer (level.Canvas), so saving the level is easy because you can just pull the Chunker out from the canvas. * ChunkSize is stored inside the level file and the default value is at balance/numbers.go: 1000
2018-09-23 22:20:45 +00:00
Play: Autoscrolling and Bounded Level Support Implement scrolling behavior in Play Mode by allowing the Canvas to follow a specific actor and keep it in view. The Canvas has a FollowActor property which holds an ID of the actor to follow (if blank, no actor is being followed). In Play Mode the Player is followed and when they get too close to the left or right edges of the screen, the level will scroll to try and catch them. If the player is moving very fast they can outrun the camera. The bounded levels are enforced in Play Mode and the camera won't scroll to view pixels out-of-bounds and the Doodad actors inside the level aren't allowed to exit its boundaries. This is global, not only for the Player doodad but any Doodad that came with the level as well. Other changes: - Restructured Canvas widget code into many new files. The Canvas widget is shaping up to be where most of the magic happens, which is okay because it's close to the action and pulling the strings from outside would be harder, even tho as a UI element you think it should be lightweight. - Debug Overlay: added room for Scenes to insert their own custom Debug Overlay key/value pairs (the values are string pointers so the Scene can update them freely): - The core labels are FPS, Scene and Mouse. The Pixel (world coordinate under cursor) is removed from the core labels. - Edit Scene provides Pixel, Tool and Swatch - Play Scene provides Pixel, Player, Viewport, Scroll
2018-10-29 00:33:24 +00:00
// Window scrolling behavior in Play Mode.
ScrollboxHoz = 64 // horizontal pixels close to canvas border
ScrollboxVert = 128
ScrollMaxVelocity = 24
// Player speeds
PlayerMaxVelocity = 12
Gravity = 2
Implement Chunk System for Pixel Data Starts the implementation of the chunk-based pixel storage system for levels and drawings. Previously the levels had a Pixels structure which was just an array of X,Y and palette index triplets. The new chunk system divides the map up into square chunks, and lets each chunk manage its own memory layout. The "MapAccessor" layout is implemented first which is a map of X,Y coordinates to their Swatches (pointer to an index of the palette). When serialized the MapAccessor maps the "X,Y": "index" similarly to the old Pixels array. The object hierarchy for the chunk system is like: * Chunker: the manager of the chunks who keeps track of the ChunkSize and a map of "chunk coordinates" to the chunk in charge of it. * Chunk: a part of the drawing ChunkSize length square. A chunk has a Type (of how it stores its data, 0 being a map[Point]Swatch and 1 being a [][]Swatch 2D array), and the chunk has an Accessor which implements the underlying type. * Accessor: an interface for a Chunk to provide access to its pixels. * MapAccessor: a "sparse map" of coordinates to their Swatches. * GridAccessor: TBD, will be a "dense" 2D grid of Swatches. The JSON files are loaded in two passes: 1. The chunks only load their swatch indexes from disk. 2. With the palette also loaded, the chunks are "inflated" and linked to their swatch pointers. Misc changes: * The `level.Canvas` UI widget switches from the old Grid data type to being able to directly use a `level.Chunker` * The Chunker is a shared data type between the on-disk level format and the actual renderer (level.Canvas), so saving the level is easy because you can just pull the Chunker out from the canvas. * ChunkSize is stored inside the level file and the default value is at balance/numbers.go: 1000
2018-09-23 22:20:45 +00:00
// Default chunk size for canvases.
WIP Finishing Up Texture Caching System Apart from putting the cached bitmaps in a better place, this about finishes up the texture caching optimization and IT IS FAST! When I spam drag a lot of pixels around the FPS may drop to the 40's but once the caches are warmed up the FPS returns to 60 and stays there, even if the screen is very busy with pixels. An undocumented debug feature: set the environment variable DEBUG_CHUNK_COLOR='#00FFFF' to set a bitmap background color besides white to be used when caching the chunks. It helps to visualize where on the screen the bitmaps are being used. May go away in the future. Changes: - Found that the old default chunk size of 1000 was slow to generate bitmap images to cache. The 100px test size was fast and 128 sounds like a good middle ground number to pick for now. - Fixed all the problems with scroll behavior and offset by inverting the sign of the scroll behavior. Scrolling to the Right and Down actually subtracts X,Y values instead of adds them.
2018-10-18 06:01:21 +00:00
ChunkSize = 128
Doodad Edit Mode: Saving and Loading From Disk Adds the first features to Edit Mode to support creation of Doodad files! The "New Doodad" button pops up a prompt for a Doodad size (default 100px) and configures the Canvas widget and makes a Doodad struct instead of a Level to manage. * Move the custom Canvas widget from `level.Canvas` to `uix.Canvas` (the uix package is for our custom UI widgets now) * Rename the `doodads.Doodad` interface (for runtime instances of Doodads) to `doodads.Actor` and make `doodads.Doodad` describe the file format and JSON schema instead. * Rename the `EditLevel()` method to `EditDrawing()` and it inspects the file extension to know whether to launch the Edit Mode for a Level or for a Doodad drawing. * Doodads can be edited by using the `-edit` CLI flag or using the in-game file open features (including `edit` command of dev console). * Add a `Scrollable` boolean to uix.Canvas to restrict the keyboard being able to scroll the level, for editing Doodads which have a fixed size.
2018-09-26 17:04:46 +00:00
// Default size for a new Doodad.
DoodadSize = 100
Abstract Drawing Canvas into Reusable Widget The `level.Canvas` is a widget that holds onto its Palette and Grid and has interactions to allow scrolling and editing the grid using the swatches available on the palette. Thus all of the logic in the Editor Mode for drawing directly onto the root SDL surface are now handled inside a level.Canvas instance. The `level.Canvas` widget has the following properties: * Like any widget it has an X,Y position and a width/height. * It has a Scroll position to control which slice of its drawing will be visible inside its bounding box. * It supports levels having negative coordinates for their pixels. It doesn't care. The default Scroll position is (0,0) at the top left corner of the widget but you can scroll into the negatives and see the negative pixels. * Keyboard keys will scroll the viewport inside the canvas. * The canvas draws only the pixels that are visible inside its bounding box. This feature will eventually pave the way toward: * Doodads being dropped on top of your map, each Doodad being its own Canvas widget. * Using drawings as button icons for the user interface, as the Canvas is a normal widget.
2018-08-17 03:37:19 +00:00
)
Drag Doodads Onto Levels in Edit Mode Add the ability to drag and drop Doodads onto the level. The Doodad buttons on the palette now trigger a Drag/Drop behavior when clicked, and a "blueprint colored" version of the Doodad follows your cursor, centered on it. Actors are assigned a random UUID ID when they are placed into a level. The Canvas gained a MaskColor property that forces all pixels in the drawing to render as the same color. This is a visual-only effect, and is used when dragging Doodads in so they render as "blueprints" instead of their actual colors until they are dropped. Fix the chunk bitmap cache system so it saves in the $XDG_CACHE_FOLDER instead of /tmp and has better names. They go into `~/.config/doodle/chunks/` and have UUID file names -- but they disappear quickly! As soon as they are cached into SDL2 they are removed from disk. Other changes: - UI: Add Hovering() method that returns the widgets that are beneath a point (your cursor) and those that are not, for easy querying for event propagation. - UI: Add ability to return an ErrStopPropagation to tell the master Scene (outside the UI) not to continue sending events to other parts of the code, so that you don't draw pixels during a drag event.
2018-10-20 22:42:49 +00:00
// Edit Mode Values
var (
// Number of Doodads per row in the palette.
UIDoodadsPerRow = 2
)
Reference in New Issue Copy Permalink