Lodestar

After converting the scripted data elements into pure TML data...

Tue, 30 Apr 2013 07:27:29 -0700

After converting the scripted data elements into pure TML data elements, I decided to also convert the noise function definitions to pure TML data definitions. Before doing this, however, I wanted to consolidate and expand my noise library. I was using value noise and had noise code spread out all over the project.

In my noise research, I ran across Joshua Tippetts’ Accidental Noise Library written in C++. It is modular and supports 2d, 3d, 4d and 6d noise. All the d’s you’d ever need. Also, its modular nature lends itself well to the data-driven function chaining that I want my modders to have access to.

During the process of porting the lib to Java, I soon wished I had a way to visualize how the functions were chained and be able to adjust parameters and chaining while seeing the results in real-time. That led to the development of the visual layer you see above with the blue grid background.

The visual layer let me test new modules / functions and quickly see the results. Since I would be using the chained noise functions predominantly for terrain generation (2d value maps), I also wanted a way to see what the terrain might look like without having to export the chain, load up the game and click through to see it. That led to the blocky 3d preview you see above.

The 3d preview runs as a server listening for connections from the 3d output modules in the visual layer. Whenever it receives a new array of values, it rebuilds and displays the output accordingly. This let’s me put the 3d preview on any machine, and just leave it running.

I think this is going to dramatically cut down the time spent tweaking noise.

The visual layer and 3d preview is not freely available, however the underlying noise lib is open-source: https://github.com/codetaylor/Joise

Tuple Markup Language

Fri, 26 Apr 2013 09:12:03 -0700

tl:dr I rewrote Google’s Gson JSON library for use with TML. If you use Java and want clean, human-readable/editable data, use it.

https://github.com/codetaylor/Juple

Initially I decided to expose game data via scripts, or rather through a Java api. The scripts were just java classes that got loaded dynamically at run-time. Now keep in mind I’m just talking about data, not logic. This seemed like an awesome idea at first. Then I started using it.

It quickly became apparent that there was too much overhead, boiler-plate, cruft-shifting type coding going on. If I wanted to add a property to something, first I had to define it in the API, then go write the code to handle populating the value in-game, and finally, go modify the script. On top of that, there was the Java-doc for the API that would have to be kept up to date, not only for the data mapping methods, but also for the logic.

If I have a game entity that has four values, I don’t want to have to define a package, define imports, think of a clever class name (or concoct a new naming convention), write an interface in the API, write the class loading code, write the definition handling code, update the java-doc… ugh. Monolithic Sisyphus syndrome.

After a little thought, I decided to split the data definition from the scripting altogether. Scripts will now simply exist for logic and data will be defined without logic. Not to say that data will be generated illogically. A sniper? Let’s give her a hand-to-hand combat bonus. What? I didn’t see an ‘if-then’! No no… I digress.

The first tech that came to mind was XML. I played about with XML for a bit and then moved on to JSON. XML felt too cumbersome for what I imagined and JSON was a move in the right direction. Google has a pretty robust, open-source Java JSON lib called Gson, and I really liked how easy it was to use and extend. Then I ran across TML…

TML, or Tuple Markup Language, is a minimalist, all-purpose markup language created by John Judnich. I thought to myself, “That’s it! That’s what I’m going to use!” I delved into the GitHub repo.. ok C, C++, Javascript, Python: no lib for Java. So sad. Back to JSON I went, sighing all the way.

I was writing stuff like this:

{
    "first name": "John",
    "last name": "Smith",
    "age": 25,
    "address": {
        "street address": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": 10021
    }
}

…while dreaming about stuff like this:

[
    [first name | John]
    [last name | Smith]
    [age | 25]
    [address |
        [street address | 21 2nd Street]
        [city | New York]
        [state | NY]
        [postalCode | 10021]
    ]
]

I felt like I was painting with rocks. I just had to have the power and flexibility of the Gson lib, but for TML.

That’s why I rewrote Gson for TML… FTW.

It’s free, open-source, and has some decent docs, check it out.

My friend is about halfway done with a ship model and texture...

Sun, 07 Apr 2013 13:53:52 -0700

My friend is about halfway done with a ship model and texture for the new game screen. Today I dropped it in to get an idea of how it will look.

It’s been almost two months since I started a major...

Sun, 24 Mar 2013 23:37:44 -0700

Refactoring glitch

Refactoring glitch

It’s been almost two months since I started a major refactor on the context, input, state, asset, scene graph, shader and render systems. I’m pleased to say that the engine is just about back to where it was before I started, with some very beneficial added functionality.

Context System

The rendering context now exists in its own thread and fires events to its listener, the main application. Some of the event methods include initialize(), update(), restart(), stop() and destroy(). The other system components can then be established with access to the rendering context in the listener’s initialize() method. Inside the main game loop, the update() method, all of the other system components are updated. Changing the display properties calls the restart() method causing the render manager and GUI to update with respect to the new properties. The restart() method allows the context to be restarted at any time during the execution of the application without interruption; basically changing any display property will no longer force a restart of the entire application. When the player requests to exit the application, the stop() method is called and after the context is destroyed, the destroy() method is called.

Input System

The old input system was very concrete, inflexible, and too many other systems were dependent on a specific output from the input manager. This became problematic when refactoring the core systems that were too tightly integrated with the input. The new input system uses components that separate the underlying input messages from the output. Keys, buttons, and axes can be mapped to the input system as triggers for defined events and listeners can be registered to listen for those events. Keyboard and mouse input components have been written and other components can be easily written and implemented in the future. Components for joystick or touch-based input could be swapped in without changing any game code. Additionally, this redesign makes user defined controls very easy to implement.

State System

Game states should not be a set of enums in a switch managed by a singleton. Singletons are like drugs; use one and pretty soon you’re using them all the time, all over the place. It wasn’t long before I had state changes being triggered from code that shouldn’t care about state. This design is naive and gets out of hand rapidly, so needless to say, the old state system was stupid. The new system uses state objects that are initialized and updated in the rendering thread, giving the states access to the application systems and the scene graph. States can encapsulate different portions of game logic; they are kept tidy and clean up after themselves. For example I have a state to control display and interaction with the main menu, a state to display and update the scene graph objects (planet, skybox) in the main menu, and a state that starts the game server and listens and reacts to state changes within the server. The state objects can now be cleanly used to separate different kinds of game logic.

Asset System

The decision to undergo a major refactor stemmed from the need for better asset management. The old asset system loaded assets like images, fonts and models into memory and kept a hard reference. That’s it. There wasn’t even a way to unload dead assets. The new asset system leverages the java.lang.ref package, specifically the PhantomReference and WeakReference, to automatically free memory from unused assets when it’s needed. Some asset types are cloned from the original cached asset when requested. This allows the properties of the cloned asset to be manipulated independently from the other instances of the asset while still maintaining a reference to the shared asset data. The asset manager keeps track of the clones and, when the garbage collector deems that none of the clones are reachable, it cleans up the original asset if the memory is needed.

Scene Graph

The scene graph underwent many internal changes, but the overall functionality is relatively unchanged. The old scene graph used separate nodes for rotation, translation and scale. The new scene graph combines the three into a single transform for each node and, instead of converting quaternions to rotation matrices and multiplying those, it simply uses quaternions for rotation. Some optimizations were made to the way the scene graph is updated. Previously, the transform data for each node in the scene graph was calculated every frame. Now, only the nodes that need to be updated are calculated.

Render System

The render system underwent internal changes in the way that the renderable nodes are queued, culled and rendered. These changes aren’t really worth going into detail about. One change that is worth mentioning, however, is the way that the render system handles assets that are uploaded to the GPU such as textures and buffer data. It uses a method similar to the method used by the asset manager and leverages the java references to be notified when an uploaded asset is no longer reachable CPU-side. When the system is notified of a dead GPU asset, the asset is removed from the GPU. Another new feature of the render system ties into the new asset management. The asset caches can be cleared of specific types of assets, then the render system forced to re-initialize all attached rendering components. These two features, when combined, can be used to instantly reload shaders without restarting the application.

Shader System

All of the shaders are now GLSL 1.5 core instead of GLSL 3.3 core. This was done in response to shader compilation errors on OSX, which as I understand, is limited to OpenGL 3.2 and GLSL 1.5. When shader assets are loaded, they can be assigned global uniform bindings, which consist of commonly needed uniforms, such as the view matrix and projection matrix. When the shader is enabled, the global bindings are checked and updated. Technique specific uniforms exist within the lightweight technique objects and are updated in the same fashion. Many techniques can have a reference to the same shader asset, yet have different values for the technique specific uniforms.

The old shader system used the positions of the far corners of the frustum in view space to cast a ray through a clip space fragment position and reconstruct the view space position of the fragment from the gbuffer’s depth texture. The frustum corner positions were calculated and passed into the shader every frame. Now the frustum corners are calculated in the shader by multiplying the full-screen quad corners by the inverse of the projection matrix.

The particle code is shaping up nicely. This is now the third...

Sat, 26 Jan 2013 10:38:17 -0800

The particle code is shaping up nicely. This is now the third re-design from the ground up and this is the one that I’m sticking with. I decided to use the CPU for particles. Yes, it is limiting and, yes I am aware of things like texture-data, transform feedback VBO, and OpenCL particle systems that run in parallel on the GPU. I chose to implement particles on the CPU because I wanted to have a modular system that was easily extensible. I didn’t want to write a tool that would dynamically generate a shader or OCL kernel for every possible combination of parameter manipulation modules. I wanted to have access to the particle data in order to do things like per-particle light sources and collision.

The current system meets these needs by using what I’m calling modules. Modules implement interfaces and are assigned to emitter definitions; essentially a form of dependency injection. Emitter definitions are collected within system definitions or assigned to other emitter definitions as child emitters that spawn either at the birth of a particle or on the death of a particle. Particles exist in an array and are generated on start-up. The particle pool manages particles by allowing emitters to request either a sorted or unsorted particle, and allows a maximum of 10k sorted and 20k unsorted particles.

When the particle manager receives a request to create a new particle system from a definition and attach it to the scene graph, it creates a new system instance, and subsequent emitter instances. The instance classes are very lightweight and contain instance specific members such as system world position, emitter position relative to the parent system, active particles, and counter modules copied from the definition. Each emitter contains a reference to it’s definition and, during the particle update loop, the modules attached to the definition are called and passed a particle to act upon.

Using a modular dependency injection in this way greatly reduces conditional branching within the update loop and allows new behavior models to be added quickly, easily, and with very little risk of breaking the save format.

Features:

Position modules
Velocity modules
Acceleration modules
Rotation modules
Animated vector flow field based on Perlin noise
Textures
Billboard, +x facing, +y facing, +z facing
Double sided with reversed texture on back
Keyframe interpolation for color, alpha, size, texture index, rotation
Burn parameter for smooth interpolation between alpha and additive blending
Emissive parameter

Total Project Statistics:

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           645          15593           7098          45229
PHP            309          10275           5858          26722
CSS              6            641             68           3242
GLSL            62            458            130           1839
Javascript      14            262             89           1192
XML             11            158             16            771
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:          1051          27395          13259          79038
---------------------------------------------------------------

Photo

Mon, 14 Jan 2013 14:00:56 -0800

Not sure if art or bad buffer stride.

Sun, 13 Jan 2013 14:01:03 -0800

Not sure if art or bad buffer stride.

Update 0.0.146e is live! This update has a few fixes and one...

Thu, 03 Jan 2013 15:13:20 -0800

Update 0.0.146e is live!

This update has a few fixes and one major addition: sprite animation editor! Currently the animator supports three types of interpolation: step, linear and cosine. Initially I had planned to also use cubic interpolation like a Hermite or TCB spline, but decided against it. The cosine has some of the features of a parameterized spline, like the smooth ease-in and ease-out, but lacks the fine-tuned control of a TCB spline. I’m ok with that for now. The cosine interpolation is cheap and the sprites are blocky. Seriously, how much granularity do we need here?

There is now an envelope editor that allows you to visualize all of the keyframes in the timeline for each transform and assign an interpolation type for each axis.

Lodestar:
* Fixed crash report newline spacing… again

Launcher:
+ Added animator to the menu
* Fixed empty menu on initial download

Sprite Animator:
+ Initial release; v0.1b

Sprite Editor:
+ Added hotkey Q for Add
+ Added hotkey E for Paint
+ Added hotkey S for Erase

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           483          12830           5477          37052
PHP            309          10275           5858          26722
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML             11            158             16            771
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           881          24581          11619          70601
---------------------------------------------------------------

Didn’t get much done this week with the holidays and all,...

Sat, 29 Dec 2012 14:01:01 -0800

Framework

Keyframes and quaternions

Models

Didn’t get much done this week with the holidays and all, so I’m afraid there will be no update this weekend. I did get a great start on the animator and I hope to release it in next weekend’s update. Stay tuned!

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           472          12499           5307          35440
PHP            309          10275           5858          26722
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML             10            134             14            669
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           869          24226          11447          68887
---------------------------------------------------------------

Version 0.0.144e is live! This week was spent adding features to...

Sat, 22 Dec 2012 10:33:31 -0800

Origin

New procedural color preview

Widescreen view & better selection controls in 3D

Luminosity preview

Symmetry

Version 0.0.144e is live!

This week was spent adding features to the sprite editor and I’m proud to say it’s done and time to move on to the animation editor. Here are some screens and the changelog.

I have nightmares about Java layout code.

Launcher:
* Fixed Windows Aero graphical glitch

Sprite Editor:
+ Palette string tags
+ Improved selected swatch indicator
+ Widescreen view
+ Center pane now uses all available space
+ Procedural HSB palette variance
+ Improved color preview in swatch editor and swatch selector
+ Scroll wheel scrolls through slices when hovered over slice view
+ Selection tool with selection size and location modification
+ Cut / copy / paste selection
+ Undo / redo paste selection
+ Fill, paint, delete selection
+ Select all
+ Crop to selection
+ Resize sprite
+ Clear palette button
+ Symmetrical editing: paint, fill, add, erase and most selection edits
+ Hold A, W, or D and scroll to move selection in 3D view
+ Hold A, W, or D + LShift to size selection in 3D view
+ Copy / paste palette swatches
+ Luminosity value for each palette swatch
+ Luminosity preview mode in 3D view
+ Swatch edits and pastes can now be undone
+ Redo functionality
+ Grid and sprite bounds visualization in 3D view
+ Origin editing
* Fixed timer thread shutdown bug
* Fixed duplicate filename extension bug

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           413          11046           4183          30782
PHP            309          10275           5858          26722
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML             10            134             14            669
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           810          22773          10323          64229
---------------------------------------------------------------

Update 0.0.143e is live! For those of you who don’t know,...

Sat, 15 Dec 2012 14:01:45 -0800

Update 0.0.143e is live!

For those of you who don’t know, you can snag the software and all future updates for only 5 USD in our store. This update includes the 3D sprite editor, accessible from the little toolbox in the corner of the launcher. Get in early before the price goes up! Lodestar is still early in development and every little bit helps. :D

Keep in mind you will need a video card capable of at least OpenGL 3.3 and Shader Model 3.0 to run the software. The 3D sprite editor will run with OpenGL 1.1.

Here are the patch notes:

+ Added 3D Sprite Editor v0.1 to tooklit
+ New launcher
+ Access toolkit resources from launcher
+ Improved error handling
* Server threadpool now shuts down properly
* Fixed server crash when duplicate players try to connect
* Fixed five second session expiration bug
* Fixed silent crash when starting a game
* Crash report now generates proper newline for the issue tracker
* Fixed pre-launcher crashing when no internet connection
* Fixed pre-launcher Java 6 only requirement; now accepts 6 or 7

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           392          10315           4126          27732
PHP            309          10275           5858          26722
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML             10            134             14            669
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           789          22042          10266          61179
---------------------------------------------------------------

Sprite editor in progress… will be in the update this...

Fri, 14 Dec 2012 14:01:03 -0800

Introductory mock-up with 3D view

Indexed palette and editing capability

Arbitrary sized sprite maps and file IO

Converter to load the old LSS sprite format

Axis indicators, paint / add mode, slice bounds visualization

Sprite editor in progress… will be in the update this weekend!

I had to write a converter to be able to load in the old LSS sprite format. As you can see by the picture with the orange hair, the old format was somewhat wasteful. Also, I ran into a problem: the old format uses three floats per voxel to represent color whereas the new format uses 16 indexed colors. This means that the old format used way more than 16 colors.

When I first loaded the sprite with orange hair, I used a simple bit of code that just put the first 16 unique colors into the swatches. All swatches were filled with various shades of orange. Not good.

So I thought about it a little bit. RGB values from 0.0f to 1.0f can be thought of as three dimensional points in the first (+, +, +) octant. Therefore it should be pretty straightforward to use the distance formula [ d = sqrt(deltaX^2 + deltaY^2 + deltaZ^2) ] as a measure of how similar two colors are. Testing against a threshold [ if d < threshold … ] allows subsequently discovered colors to use an existing indexed color if the new color is close enough.

It’s not perfect as it still produces some anomalous results, but it’s good enough to retrieve some of the hard work I put in on the old sprites a year ago.

Current features include:

Saving / loading sprites
Importing / exporting palettes
Importing old LSS sprite format
Slice bounds visualization in 3D view
View only selected slice in 3D view
Axis indicators in 3D view
View any of the 4 views fullscreen
16 indexed colors
Paint / add / erase in slice view
Sprite sizes (1, 1, 1) - (64, 64, 64)
Rotate / pan / zoom 3D view
Paint / add / erase in 3D view
Slice fill (not pictured)

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           380          10137           4127          26833
PHP            309          10275           5858          26722
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML              9            111             12            574
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           776          21841          10265          60185
---------------------------------------------------------------

New launcher ready for next update.

Thu, 13 Dec 2012 14:01:05 -0800

New launcher ready for next update.

Improved error handling for the networking and scripting. Known...

Mon, 10 Dec 2012 14:01:13 -0800

Improved error handling for the networking and scripting. Known errors that can be handled are displayed while everything gracefully saves and terminates in the background, returning the player to the title screen. The client no longer bombs all the way out when a minor exception is thrown.

http://cloc.sourceforge.net v 1.56

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
PHP            308          10266           5858          26710
Java           354           9468           3860          24074
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML              9            111             12            574
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           749          21163           9998          57414
---------------------------------------------------------------

Here’s a sneak peek at what the scripts look like. This...

Fri, 07 Dec 2012 14:00:50 -0800

Here’s a sneak peek at what the scripts look like. This code, exposed through the ‘scripting’ API, generates the rudimentary biome that you’ve seen in all my screenshots.

I refer to the files as scripts, but they’re really just Java source files.

I’m currently employing Janino as a lightweight run-time compiler that generates Java bytecode from .java files. The scripts are loaded and compiled whenever a game is started. Additionally, the scripts are sandboxed, allowing only a select whitelist of packages to be imported, and run server-side only. The API exists simply as a collection of interfaces, enums and statics.

The current API allows you to define blocks and biomes. When defining a biome you can register different value map plugins and test against those within the registered processing plugin. At this point the value maps consist of layered value noise combined in different ways.

The goal is to allow players to script their own unique experience and share that with other players without the need for all players to have the same files. The API is documented and will be available as a compiled library and source package for easy integration into your favorite Java IDE. I will find an online home for the JavaDoc as well.

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
PHP            308          10266           5858          26668
Java           356           9439           3839          23690
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML              9            101             12            510
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           751          21124           9977          56924
---------------------------------------------------------------

LAN host auto-discovery is working smoothly...

Tue, 04 Dec 2012 14:01:13 -0800

LAN host auto-discovery is working smoothly now.

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
PHP            308          10266           5858          26668
Java           340           9478           3707          23564
CSS              6            641             68           3242
GLSL            54            407            111           1579
Javascript      14            262             89           1192
XML              9            101             12            510
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           735          21163           9845          56798
---------------------------------------------------------------

Total Count

Fri, 30 Nov 2012 14:02:18 -0800

Thought I’d share my stats on the entire project so far. This count includes the web api, web app, web core, web backend, game client, game server, game pre-launcher, and game launcher. I took care to exclude the PHP libraries that I did not write.

The web core is code shared between the web app and web backend. The web app handles player registration and account maintenance. The game pre-launcher updates the launcher and the launcher handles player authentication and game file updates; both use the web api. The game client and game server authenticate to each other and to the web app via the web api.

You can visit the web app here: https://lodestargame.com/home

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
PHP            308          10266           5858          26669
Java           330           9317           3682          22777
CSS              6            641             68           3242
GLSL            54            402             86           1565
Javascript      14            262             89           1192
XML              9            101             12            501
HTML             3              8              0             42
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           725          20997           9795          55989
---------------------------------------------------------------

The networking code is up and running! When a player starts a...

Thu, 29 Nov 2012 14:01:02 -0800

The networking code is up and running!

When a player starts a game, single or multi-player, the server application launches in a separate thread and generates an asymmetrical encryption key-pair. When a remote client connects, after the handshake, the server sends the public key and a challenge. The client generates a symmetric, secret key, encrypts both the secret key and challenge with the server’s public key, and sends them back. The server then decrypts and verifies the challenge, verifies some other stuff, assigns the secret key to the player’s connection, and tells the client that all is well. The client switches to encrypted mode and all further communication between the client and server is encrypted after serialization.

If the connecting client is local, as in single player or multi-player host, the server and client switch transport mechanisms. This allows them to bypass the 7-layer burrito, bypass the encryption and serialization, and directly deliver packets to each other internally.

Both transports use the same packet protocol and it’s easy to switch the local mode to use the remote transport on localhost for testing and debugging. When using the remote transport, packets can be encrypted and/or compressed after serialization. Structuring the code this way means that as I develop, I will be forced to use the protocol and think in terms of server <-> client architecture at all times.

The offline mode indicator at the bottom is displayed when playing the game in offline mode. Go figure. You can choose to play in offline mode if you cannot connect to the server to verify your account. Unfortunately, you will not be able to enjoy multi-player or some extra perks, like rewarded titles and custom player sprite, when playing in offline mode.

http://cloc.sourceforge.net v 1.56 T=1.0 s (369.0 files/s, 34135.0 lines/s)

---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           312           7896           3506          20464
GLSL            54            402             86           1565
XML              2             34              4            177
DOS Batch        1              0              0              1
---------------------------------------------------------------
SUM:           369           8332           3596          22207
---------------------------------------------------------------

Scrollbars are done… kind of a pain in the...

Thu, 22 Nov 2012 14:00:41 -0800

Scrollbars are done… kind of a pain in the ass.

Features:

click the arrows to inc/dec by smallStep
click the empty track to inc/dec by largeStep
hover and scroll mouse to inc/dec by smallStep
click and drag thumb to directly set value
thumb size proportional to data displayed
optional Skynet uplink for enhanced scroll precision

I think everyone should have to code a text input control. It...

Sun, 18 Nov 2012 14:00:34 -0800

I think everyone should have to code a text input control. It builds char[].

I’ve come to a point where I can no longer put off the text input. Inspired by the recent text input adventures of Hume over at humespeaks.tumblr.com, I decided to buckle down and handle it.

The current iteration has most of the amenities you look for in a text box. Things like a movable, blinking horizontal and vertical cursor, key repeat with adjustable delay and repeat rate, accepted character filter, home, end, backspace and delete. It also supports arbitrary fonts, font sizes, and kerning.

I imagine this is much more difficult with a lack of string abstraction.

Also, this:

http://cloc.sourceforge.net v 1.56
T=2.0 s (160.0 files/s, 14882.0 lines/s)
---------------------------------------------------------------
Language     files          blank        comment           code
---------------------------------------------------------------
Java           264           7373           3309          16808
GLSL            54            402             86           1564
XML              2             35              4            183
---------------------------------------------------------------
SUM:           320           7810           3399          18555
---------------------------------------------------------------

Not sure why it says only 160 files and 14k lines in the top part. That is obviously not right.

As it turns out, during the creation of this control, I discovered a substantial bug in my text renderer. The renderer was using glBufferSubData to buffer new VBO data into the eldest VBO in the cache. Note: This doesn’t work when the VBO data you’re replacing is smaller than the data you replace it with.