I think you should stop distro hopping.

There is nothing quite like the thrill of installing a fresh new OS. Starting with a clean slate every few months can be very cathartic, but if all you do is switch distros, the only thing you get good at is installing Linux, not using Linux.

People will move heaven and earth to not upgrade Windows. Understandable since every new version of Windows is even more user hostile than the previous one. Even though it sucks, it's consistent. You can change browsers, and even the shell before windows 11 (not sure if you still can).

But there are probably hundreds of distros at this point, which one? I guess that's part of the problem is that each one has its own reason to use it. 

The best Linux is the one that's already installed. If you have a steam deck you probably won't want to install Ubuntu. While it's doable, steam OS is already optimized. 

If you have a NAS or another appliance, it's probably not going to make a lot of sense to switch. 

So let's talk about desktops and laptops. 

If you have a desktop with a keyboard, mouse, a screen and speakers, and nothing weird, you should be alright with any of them. Find one, and stick with it. 

Fine. I'll pick for you. 

Kubuntu.

The stability of Ubuntu with the familiarity that kde has to offer. Kde looks and feels like windows. If you are used to windows, use this. 

If you are coming from Mac, use plain Debian with the gnome desktop.

Then from then on, figure out how to use the OS. 

Day to day there isn't much difference between gnome on Debian and gnome on fedora. You have the same apps, same command line tools, the same kernels. The major difference is how you get your software and even this is getting easier. 

Flatpak saves the day in a huge way if you are mostly comfortable in the GUI. For apps you don't need to use sudo with, it's great. 

If you have a laptop... Things get messier. 

If you have an AMD based machine you are probably just fine. AMD has had open drivers for a long time and either distro listed above should work just fine. 

If you have an Intel based machine, life is also pretty good. Again, mostly open drivers ecosystem. 

If you have a laptop with a discreet GPU, specifically an nvdia one, be prepared to suffer greatly. This has just been my experience with any dgpu laptop. Windows, Linux, or something else. 

It's too hands on to be a good experience. Having to juggle which app runs on which GPU, and which power settings do you need to use in which scenario is always painful.

What's even worse is actually trying to game on these. Enjoy constant stuttering from the power starved GPU. Enjoy horrible frame pacing. Maybe if you set everything to full throttle you won't have frame skips from dynamic power adjustment. But good luck hearing anything over the fans.

So, kubuntu, or Debian, but preferably whatever ships on your device. 

Building an arcade machine - part 1 - planning

So I've decided to make my own arcade machine. It's going to be a little different than most MAME and emulator setups out there. Unlike most table tops, this one is going to be a head to head machine. I am going to take the output from the computer and run it through a VGA splitter. That way both players will see the same output, just sitting across from each other instead of side by side.

I need to wait for some more hardware to arrive before I can really begin to plan it out, but here is a preliminary basic design.

My big concern is that with this configuration, it's over 40" long. Granted, arcade machines are not small devices, but it would be nice to have something that can actually sit on the counter and be moved without me worrying about it falling apart.

Another concern is that because it's so narrow, it will have to have a substantial base to sit on such as a kitchen counter or a table.

I'm thinking that I want to use pine for this project because it's very light, strong, and easy to work. I know next to nothing about wood working, but now is a great time to learn.

The above is just the skeleton.  The side panels will actually be stylized. I want to make them sort of match up with the Atari logo.

Which I would like to get as a decal.

I have ordered the monitors, off lease, from ebay. They are two dell 2001fps. They are 20 inches with a 4:3 ratio and 1600x1200 maximum resolution. This should be the next best thing to using an actual CRT.

And finally, the last component, which I already own, is the mayflash universal fight stick.

I'll be honest, it's not a great device. The stick isn't tight and the buttons are mushy, but it works with everything and the base is solid metal. Also, I got them both for a great deal. Further down the line, if I see benefit to it, I should easily be able to change out for an ipac or something similar.

voidskimmer 2014 11 24

Doing some interesting and complicated things with a rendertarget2d.

Planning development for voidskimmer.

So I have written two demos for void skimmer. One that demonstrates ship movement, and one that demonstrates the parallax effect by projecting the game field onto a cylinder. Now it's time to actually sit down and write the game.

Up until now I've been able to get away with using scalars or simple objects, but I want to be easily able to scale the game into something larger. I don't want to write my own engine, but I need to find a way to make certain things extensible.




I think that with the game I am working on, it would be nearly impossible to develop as an MVC style application. The coupling is simply to tight.

So let's take a look at the game objects to get a better idea of what design pattern to use.

So far, we have a playfield and a space ship.

A play field has dimensions, a background image, physics, gravity, objects, etc.

A space ship is an object, it has a position, velocity, and a heading, it has a sprite, fuel, health, etc.

Now here is an interesting question. Is a play-field a level, or does a level merely populate a level? What conditions cause you to change levels? How do you manipulate the space ship object?

How are objects drawn? Do space ships draw themselves? Does the play-field draw the space ship? Does the game object draw all the game elements?

Is a game object just a game object, and the play-field does all the controlling, or will a space ship object inherit from a base game object?

There are two things I want to avoid in designing this game. Over abstraction, and over complication. I don't have an existing code base to work off of, and no team mates to code it with me, so having large complicated objects just slows things down.

voidskimmer 2014 11 22

This game is very much me cobbling together pieces as I can find time to. Today I got a very basic carousel working that the actual game will be projected on. The next video should hopefully combine the two concepts.

Void Skimmer update

Just another update on the progress of my tiny game that I'm working on.

It's coming along pretty nicely. One thing I would like to do is have a repeating background instead of just clamping the edges. If you were on the bottom of the play area shooting down, and somebody was on the top of the play area, the person on top would get obliterated hands down, because they wouldn't see the enemy or the shots coming. I think this is what I will work on adding next.

I may need to switch how I am doing the drawing though. Right now I am drawing everything twice. I am drawing the ship, the background, and all the active game objects to a reserve render target. This gives me resolution independence and the ability to do some post effects on the game screen. Sepia when paused, shake the screen when a player dies, scale the camera to encompass two players, etc.

But the problem is when things go outside the play area. The default behavior is to clamp, but I need it to repeat. 

The next thing I would like to work on is adding black hole gravity wells for your ship to encounter.

Void Skimmer Video 1

A small demo of just some simple movement mechanics that I've been working on, and getting familiar with Monogame.

It's a great library, and I'll definitely write some more about it when I have more to say about it :p

Playing around with monogame

Been playing around with monogame a little bit. Have to say, pretty impressed with how easy it is to get something on the screen.

Coincidentally, been having a lot of fun playing luftrausers on PS3 this weekend too.

Some old programming videos I made

At some point I should probably post more videos.

Catching up

Wow, it's been a while since I have posted anything cool to my blog. Right around a year actually. I think it's time to fix that. I have been doing some neat stuff like building my own software renderer and building some quake levels. Those videos are on youtube, so I will have to cross post them here.

Another cool project that I have dabbled with is creating a play-station as a service setup. Using a TV tuner card, NGinx, and a few other pieces of software, I can effectively play playstation from any device in the house (as long as I bring my controller with).

I think between that and cataloguing what I have been learning about Linux and web programming lately, there will be some pretty neat stuff coming in the year 2015.


So, the most recent thing I've done is convert my PC from running windows 7/8 to running Ubuntu full time. What a transition! I'm not sure I will stick with it, but Gnome throwback is making it a lot easier, and so is having almost half my steam library available.

Being able to play TF2 and Civ V makes me a very happy panda. In the future I may add a 3rd hdd for dual booting, but for right now, things are great.

game markup language experiment - Part 1

Going off my last post, where I described a theoretical game markup language, mixed with JavaScript and a type of CSS, I've decided to go ahead and perform a theoretical experiment.

You can follow my progress here: https://github.com/longjoel/gml-experiment

For a project base, I am using C# and .NET to primarily develop this in. Because this is going to involve a lot of dynamic language processing, and XML processing, it just makes sense to use this instead of C or C++.

Processing the DOM: 

* This is easy enough to do, because C# handily supports XML Serialization and deserialization.

Handling the Javascript: 

I am trying to decide between several projects at the moment for the JS implementation. 

* IronJS - based on ecma script 3, looks stable but no longer maintained.

https://github.com/fholm/IronJS

* V8.NET - actively maintained, based on google's V8 javascript engine, should be robust and fast.

http://v8dotnet.codeplex.com/

* Clearscript - looks ridiculously easy to get started with, can use chakra or v8 JS engines, actively developed

http://clearscript.codeplex.com/

Handling the CSS:

CSS parsing will be a custom solution.

Display layer:

There are quite a few options available. There is DirectX with SlimDX. There is OpenGL via OpenTK. SDL 2.0 bindings exist as well, and that's all before we begin to look at MonoGame, XNA, or using Webkit. A decision on this does not have to be made right away. For now we can just use GDI + and a debug console.

Physics API:

Physics is another piece which will come further down the pipe. But will probably just use farseer for the time being. 

http://farseerphysics.codeplex.com/

So the first step will be to gather all the necessary dependencies together in a folder of DLLs.

Part 2 will be designing the kernel.

Crazy thought of the day.

So I've been playing with a lot of JavaScript lately. Perhaps even too much. But sometimes, thinking too hard can lead to some interesting ideas.

JavaScript is designed primarily to manipulate the DOM of an HTML web page. JavaScript + HTML + CSS is a great combination.

* HTML describes the layout of the document.

* CSS defines the attributes of the elements in the HTML document

* JavaScript can be used to manipulate both the document layout and the elements themselves.


So why can't we treat games the same way that we treat HTML documents?

What if instead of describing elements of a web page, we were instead describing the play-field of a game?

HTML -> gamedoc:

<gamedoc>
<head>
<script source='level1.js'></script>
<script source='enemies.js'></script>
</head>
<level>
<entity class='spawn'  x = '0.0' y = '1.1'/>
<entity class='enemy' />
<brush>
____ <bpoint x = '0' y = '1'/>
____ <bpoint x = '0' y = '1'/>
____ <bpoint x = '0' y = '1'/>
</brush>
</level>
</gamedoc>

CSS -> GSS:

brush{
____ texture:url(img/background.png);
____ visability:visible;
}

JavaScript:

$(gamedoc).onready( function () {

____ $('entity').think( function(t){
____ ____ $(this).x = $(this).x + $(this).vx * t;
____ });

});

So, I'm not super clever, but I think that if I were working on a game engine, I would rather have something declarative like this to work on, instead of something like Unity3d. But maybe i'm just weird like that.

Javascript is the new BASIC. And that's not necessarily a bad thing.

I think I come from the last generation of programmers that grew up learning a BASIC dialect as our first programming language. Then came Java, then Python, then C#, and now Javascript.

I grew up with Qbasic 1.1 on MS-Dos 5, chugging along on my dad's old 386sx. We didn't even have a floating point co-processor. But coding on that thing was so much fun. I made my own sprite editor, a hand full of games, and got it to do some of my math home work for me. I can even go back today, and with a little bit of reflection, do some wizardry again in that ancient old programming language. Probably the best part about programming in QBasic was that a good chunk of this was before the internet. I actually had to go to the library and check out an ancient programming manual, then figure out how to adapt it to QBasic. This was fun.

So now here I am, 20 years later. (Have I really been doing this for 20 years?) I develop .NET all day working on a CRM system. Programming hasn't really been much fun. It's been quite productive, that's for sure, but not much fun. Then I decided to put together my Romflow application. This isn't the first time I've tried to make an emulation frontend, but this is probably my best effort to date. In looking at the other options available, I wanted to make something fast, something customizable, and something easy. So instead of doing a plugin system using C# interfaces, or hardcoding something using System.Drawing, I decided to look into using a web control hosted application. And you know what? It works really really well.

Kind of. You see, I'm not very good with the HTMLs and the CSS and the Javascript. Since I graduated from QBasic, I've stuck exclusively with statically typed languages. I liked the predictability and stability, and the ease of debugging that statically typed languages had to offer. However, at least not right away, this is not really an option for working with romflow. While it's possible to design a silverlight application, or a flash application, or a dart application, it's actually just much simpler to write something in Javascript.

Even though it's simpler, it's still not all that simple. You have to remember, we are doing things to HTML that it was never intended to be doing. HTML was meant to be a document, not an application framework. Never the less though, here we are. The biggest challenge for me is working with CSS though, not even Javascript. CSS feels like the rules are made up as you go along. Especially when it comes to vertically aligning content.

Despite having stack exchange, countless forums, and numerous other resources, making a good looking web app is still a gigantic challenge. Especially if you are invoking the dreaded window.external API. But, when I actually got something working the way I wanted it to work, I was 8 again, hacking away on my dad's dying PC. Hours started to go by as every minute, my app worked a little better, and a little better still. I no longer see an empty HTML page as a portal to evil, but rather as a canvas to paint my ideas upon. Javascript is fun. And fun isn't something I've had with programming for quite a while. It's challenging as well.

Blogging is hard and stuff.

Blogging is hard. I'm still not even sure why I really try, but it really is damn hard for me to not want to obliterate my blog every few months, make a new one, then delete that one again after only making a post or two. So now I'm making it my mission to try and update at least once a week, whether I have something to write or not.

So, what have I been up to lately?

I'm trying to get myself off of Windows. Not that there is anything wrong with windows, it's just that Linux is a lot more fun. Now that steam is a viable product, and now a certain horrible hardware company's drivers are usable, there is nothing that I can do on my laptop under Linux, that I can't do under windows.

I'm also trying to teach myself Python as well. Python is a great language that gets a lot of flack for being slow. I don't care how fast it is as long as it's fast enough. For everything short of AAA game development, it's more than plenty fast.

During the day, I write C# code. All day long, it's C#, and Winforms, and SQL, and so on. I feel there is a certain advantage in separating one's work experience from their home experience. This is hard because I actually enjoy coding in C# a great deal.

But there is this certain grand elegance when coding with python. Style is something setup for you using PEP-8. There is a python library for nearly everything, and it excels on low end hardware like the raspberry pi. What really spurred me on to learn it was pycharm having a free community edition.

Still not exactly sure what I want to do with python yet, but I will post if I come up with something cool. Maybe a port or an adaption of romflow?

Romulator Lightboxing

Lightboxing. It will look better when the theme is up and running.

Romulator Update

Got quicksave, quickload and quit working. Send message is a downright pain.

http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys.aspx

Instead of deleting all the posts and starting a new blog from scratch again...

I'm just going to keep updating this one!

Right now I'm working on a emulator front-end using HTML5 as the theeming engine. Works a lot better than I thought. Right now the large part of the work remaining is coming up with a killer theme that plays nice with the game-pad interface I've set up. At some point, I should diagram all this out.

So I kind of have a dynamic code generation...

So I kind of have a dynamic code generation and execution library written in C# that works on Linux now, if you have GCC installed. It works, as long as you define your delegate ahead of time, and pass it in as part of the process. But what if you don't know what you want ahead of time? Say you want to ask the user, how many parameters do you want to pass to the function? Right now you can't generate dynamically your calls, it won't let you cheat, but I think I figured a way around this. And that is... Using the CodeDOM The CodeDOM provides types that represent many common types of source code elements. You can design a program that builds a source code model using CodeDOM elements to assemble an object graph. This o... View or comment on Joel Longanecker's post » Google+ makes sharing on the web more like sharing in real life. Learn more. Join Google+

You received this message because Joel Longanecker shared it with longjoel.baconbacon@blogger.com. Unsubscribe from these emails. You can't reply to this email. View the post to add a comment.

OpenGL Buffer Packing

This weekend I felt a drain to my creativity brought about by a combination of not feeling well, disappointment in the ending of Mass Effect 3, and actually getting decent at call of duty. Drop-box replacing some important code files with emptiness didn't help either. So I've decided to start from scratch, rather than trying to repair my existing code base.

Starting from square one usually involves a trip to good old fashioned C. If I can code it in C, I can take it anywhere. I had gotten quite good at doing OpenGL from inside OpenTK, so my idea was to take some of the  modern concepts learned from there, and apply them back in C.

Modern OpenGL consists really of two things, cramming things in to buffers, and making pretties with shaders.

So, let's talk about array buffers, no, wait, let's talk about vertexes first.

In a mathematical sense, a vertex buffer is an intersection of two or more lines in space. We use vertexes to define the bounds of our geometry instead of lines or rays. However, in OpenGL, vertexes do not just represent points in space that define boundaries of geometry. Color, texture, lighting, and other information can also be attached to a vertex as well.

There are two ways of packing data into buffers. The first way is to give each type of element it's own buffer. 

So in case A:

* vertexes would be in their own vertex buffer

* colors would be in their own color buffer

* texture coordinates would be in their own buffer

* normals would be in their own normal buffer

Case B: (Eeach vertex would contain the following)

* x, y, z (position)

* s, t (texture)

* r, g, b, a (color)

* nx, ny, nz (normal)

In general, case B is the better way to go. It only requires one bind buffer operation, vs one for each component type. 

For case A, you would do your drawing like this:

glEnableClientState(GL_VERTEX_ARRAY);

glEnableClientState(GL_COLOR_ARRAY);

glBindBuffer(GL_ARRAY_BUFFER, vertex_buffer_handle);

glVertexPointer(3, GL_FLOAT, 0, 0);

glBindBuffer(GL_ARRAY_BUFFER, color_buffer_handle);

glColorPointer(4, GL_FLOAT, 0, 0);

glDrawArrays(GL_TRIANGLES, 0, number_triangles);

...

for case B, you would draw like this:

typedef struct {

float x, y, z;

float r, g, b, a;

}custom_vertex_format;

...

glEnableClientState(GL_VERTEX_ARRAY);

glEnableClientState(GL_COLOR_ARRAY);

glBindBuffer(GL_ARRAY_BUFFER, buffer_handle);

glVertexPointer(3, GL_FLOAT, sizeof(custom_vertex_format), 

    offsetof(custom_vertex_format, x);

glColorPointer(4, GL_FLOAT, sizeof(custom_vertex_format), 

    offsetof(custom_vertex_format, r);

glDrawArrays(GL_TRIANGLES, 0, number_triangles);

offsetof is a macro defined in stddef.h http://linux.die.net/man/3/offsetof

Again, in most circumstances, method B is going to be faster. The reasoning for this is as follows.

Fewer cache misses, since all the data is tightly packed together. In case A, it might be conceivable that the vertex buffer and the color buffer might be in completely different areas in memory. In case B, each vertex should be adjacent to each other. It's also especially important when working with element arrays.

What's an element array?

Consider the following. Say you have a mesh, and in this mesh, you have multiple adjacent triangles. These triangles, 'share' a vertex. As in, the vertex has the exact same position, color, normal and texture attributes. The more attributes you have packed in your vertex, the more expensive it becomes to have duplicates in your vertex buffer.

Say you have the following vertexes 

V = {A, B, C, D, E, F, G, H, I, J}

Say your triangle mesh 

M = {A, B, C, B, C, D, C, D, E, F, G, H}

So, B is an element twice, C is an element 3 times, D is in there twice, etc. At this point, each vertex is composed of at least 11 floating point elements. If only there was a way to send each vertex to the buffer exactly once, and then just draw by index... There is!

Say V = {A, B, C, D, E, F, G, H, I, J}

and M = {A, B, C, B, C, D, C, D, E, F, G, H}

Let Mi = {1,2,3,2,3,4,3,4,5,6,7,8}

So we would bind V as our vertex buffer, and Mi as our element buffer. we would use glDrawElements instead of glDrawArrays. http://www.opengl.org/sdk/docs/man/xhtml/glDrawElements.xml

glEnableClientState(GL_VERTEX_ARRAY);

glEnableClientState(GL_COLOR_ARRAY);

glBindBuffer(GL_ARRAY_BUFFER, buffer_handle);

glVertexPointer(3, GL_FLOAT, sizeof(custom_vertex_format), 

    offsetof(custom_vertex_format, x);

glColorPointer(4, GL_FLOAT, sizeof(custom_vertex_format), 

    offsetof(custom_vertex_format, r);

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, element_buffer_handle);

glDrawElements(GL_TRIANGLES, number_triangles, GL_SHORT, 0);

Take note that we only had to bind the element array buffer in order to use glDrawElements, we didn't have to specify an element pointer, or enable the client state for it.

Also, notice that there isn't a separate element buffer for each attribute of the vertex. It sounds like it could be a great idea, but the reality is that it would be incredibly slow. It's the same reason why non-power of two textures are such a problem. It's just a constraint we have to live with.

I hope this has helped distinguish some of the differences in how OpenGL can process buffers for you.