Add No-Brain Jogging to examples

[gonutz]

Hello Michal,

first let me tell you that this is a very cool game library that you have created! In the past I have created a lot of little games and other programs in Go, I even have my own little game library which does a very similar job but has not as many features as yours.

The next Ludum Dare is coming up and I wanted to try using someone else's engine. Looking through the options I found yours very delightful, especially your little gopher game :-)

In order to get to know your engine in preparation, I ported my last Ludum Dare entry to it. This pull request is mainly to let you know about it (I know how cool it is to see others use your creations) and to say thank you for your effort to create something cool for the open source and especially the Go community! I would love to see a lot more games and desktops apps written in Go.

A second reason for this PR is that I am very proud of my little game and I think it is great fun so I want to share it with people. Your examples are basically demos to show one or two features of your library in action. The gopher platformer is the closest to a real game. Even though my game is not large or really sophisticated, it is a complete game with graphics, audio, menus, instructions, fun gameplay and high scores. I think it makes for a great addition to your example list for people to see what is possible and to have a "real-life" example of how to use both your pixel and beep libraries.

Again, you are doing a great job here, keep up the good work!

PS: I am also working on a big addition to your library, I will create another pull request when that is done... :-)

[mewmew]

@gonutz I like it! Your game is simple yet fun! The music, sound effects, etc really adds to it. Thanks for sharing :)

This is my current highscore:

[gonutz]

Wow, not bad! My personal highscore is 79 but most of my friends and family had barely reached 10 on average ;-)

[faiface]

Hey @gonutz, you're cool buddy ;).

I know how cool it is to see others use your creations

Damn right! I love it, it's one of the things that keep my spirits up!

So, I'll be happy to accept this, except well... the way you put it there it's kinda too large in the README, makes it look like the "main example", which it isn't, no matter how cool it is. I'd suggest replacing the starfield example link in the README with yours. Or if you've got some other suggestion, let me know.

Regarding your next PR, I'm excited about that. I'd suggest though you don't keep it completely to yourself, share it perhaps on our Gitter chat. You'll receive some feedback from me and others which may be very helpful and avoid wasting your time in case some of your code goes in the wrong direction. Communication is always good ;)

[faiface]

The game is super addictive btw :D. I'm terrible at calculations, so after many plays, this is what I achieved.

[gonutz]

Thanks for the compliments! :-)

48 is very good, you had to top @mewmew, didn't you? ;-)

You are right, the screenshot was twice as large as the others, I now replaced the Starfield example like you suggested, the aspect of my screenshot is different, that is why I put it on its own line before, but it still looks OK in the table I think.

As for the Gitter chat/forum, I had not even heard of it before, I am going there right now for the "announcement" :-)

[faiface]

Okay, this is fine now.

And yeah, I had to top him, but I guess he'll easily top me back considering he reached 46 in just 4 plays :D.

Anyway, thanks again for this, I'm merging now.

[gonutz]

Regarding the Gitter, I just now realized that this is not an official github thing and that it wants me to log in separately... let me just tell you what I am working on right here :-)

I am in the process of porting your engine to the Win API and Direct3D9. The goal is to make it go gettable on Windows. I have looked into your Wiki for setting up the engine on Windows and then decided to port No-Brain Jogging on my Linux machine instead ;-)

I have done these things a couple of times now, my prototype library and my previous Ludum Dare games are all done in this way. They use GLFW or SDL2 on Linux/Mac and native Winodws APIs on Windows. That is why I feel confortable porting your engine as closely as possible to what it does using GLFW (after all if I do not know exactly, I can just look into their code).

Allowing people to just go get the engine and go run and go build games without a C compiler will greatly improve its usability.

Another advantage is that the engine will not require any special OpenGL drivers or external DLLs installed on Windows. All necessary DLLs for creating a window and handling input are there on all Windows systems and even Windows 10 still has the d3d9.dll so a program built this way will run on all current Windows platforms without change. My Ludum Dare games even ran on Windows XP. I built 32 bit binaries with <= Go 1.10. Unfortunately Go 1.11 dropped XP support, but if you want to you can still use Go 1.10 anyway and have your game more easily playable on XP today :-)

As for the progress, I have the monitor functions and input support, I save the biggest part - the graphics - for later. I am doing it in a sub-package pixelwin, analogous to the pixelgl package. I have already found some things that could potentially be moved up to the pixel package. Further down the line there is the question of how to make it easy on Windows to change implementations for the user, say you have a pixelgl version of your game and want to migrate to pixelwin (if it stays this way), wouldn't it be nice to not have to change all occurrences of pixelgl to pixelwin? These are some of the things that will need to be discussed later, I am just mentioning them here for future reference. I keep a list of these as I go along porting the engine. We should not get ahead of ourselves right now, I will create another pull request when I have the port able to build the samples. Then we can see what needs to be adapted once we have something to work off of.

[hajimehoshi]

FYI: For OpenGL, I'm doing an effort to make go-gl pure Go go-gl/glow#102

[gonutz]

@hajimehoshi very cool! I think removing the use of CGo whereever we can is a great goal. Windows is the most widespread OS and using CGo on Windows is a huge pain. This is why I started getting comfortable with the syscall package and created a lot of native Windows libraries myself.

Being able to finally use Go OpenGL bindings on Windows without doing the handstand of installing some port of a Linux C compiler (it would be nice to be able to use the Microsoft compiler by the way) is something I really look forward to :-)

One advantage of having Direct3D support as well as OpenGL is that you do not need extra drivers installed. Today if you buy a laptop or PC you will usually have the latest graphics drivers installed and be able to use OpenGL >= 3.0. That said there are still many computers running Windows without the latest graphics drivers. Also think about the virtual machines running Windows, those will have trouble too if your game requires too new an OpenGL version. And being restricted to the natively supported OpenGL 1.1 on Windows is not what you want :-)

This is why I still like to suport Direct3D9. My use case is mostly game jams and other little graphics things for myself. Having these run on every Windows without a change is a very nice property to have.

PS: I might be coming for ebiten some day as well... ;-)

[hajimehoshi]

I'm not sure what @faiface would say, but as Pixel has shader API, wouldn't it be possible to use DirectX?

And being restricted to the natively supported OpenGL 1.1 on Windows is not what you want :-)

Not 2? (Personally, I'm currently satisfied with 2, but planning to update for multi samplings. I felt like OpenGL 3 is widely used on Windows, so I'm still not sure DirectX has advantage in terms of that).

BTW I'd be really happy if we had a pure Go substitute of GLFW. Your library seems very similar. Do you have a plan to make it, just offering a window and input part without DirectX part?

PS: I might be coming for ebiten some day as well... ;-)

Thanks :-)

[gonutz]

wouldn't it be possible to use DirectX?

Yes sure, that is what I am working on, Win32 API for windowing and input handling and Direct3D9 for graphics. D3D9 is comparable to OpenGL 3.3.

What I meant with being restricted to OpenGL 1.1 is that this is the OpenGL version that is, even today, supported on a fresh Windows installation. If you want any later version you have to actually go install an extra graphics driver. I actually agree that OpenGL 2 is fine for simple 2D games, in fact my prototype library uses GL 2 for rendering :-)

It is actually a very nice idea to port the Windows-specific parts of GLFW directly to Go using syscall. This could be the default on Windows while the other platforms keep using the CGo wrapper. That sounds like a big undertaking but I have not looked into the GLFW code in detail. I might put that on my list for the future as well, but porting this engine seems enough work for now :-)

[hajimehoshi]

Yes sure, that is what I am working on, Win32 API for windowing and input handling and Direct3D9 for graphics. D3D9 is comparable to OpenGL 3.3.

Huh? What about shaders?

I might put that on my list for the future as well, but porting this engine seems enough work for now :-)

Sure, then I might use your w32 lib for my Ebiten porting. Thanks!

[gonutz]

I think we are talking at different purposes here ;-)

So my idea for the shaders is to first omit it until the rest works. Once that is done we could do multiple things for DX shaders:

1. We have the users create HLSL code and make them compile their shaders with their own fxc.exe (the DirectX effects compiler). fxc.exe is available in the old DirectX SDKs or today, I think, in the Windows SDKs. The nice thing for us in OpenGL is that we compile the shaders ourselves, but I do not think this is supported for DirectX, at least I always use fxc.exe and import the resulting shader as []byte.

2. A very cool thing would to write your shaders in Go and let another tool, no matter if that is part of the engine or an extra tool, take care of compiling that to either GLSL or a compiled HLSL shader. There are some projects that translate GLSL to HLSL or vice versa and there are some abstraction languages above both that compile down to them. Using Go as the language to write your shader in and generate code from that would be yet another cool project to work on. Realistically though, option 1 is enough work and again, I will only do that once the basic functionality is in.

Cool to hear that you consider using my w32 lib, don't be shy to message me (create a Github issue, they abolished DMing I think) if you have any questions :-)

[mewmew]

My girlfriend and I made a mod :) To make the game more relaxing we added tranquilent background music, replaced the zombies with big eyed gold fish and added a bubble blaster instead of a rifle. And, to make it more challenging we added modulo.

P.S. It's not lagging on my computer, only the GIF does since I fail at screen captures.

[gonutz]

WOW! And I don't mean World of Warcraft, I mean that THIS IS AWESOME! :-D 👍

This is so cool! I can't wait to play this version :-D
I think this might be what I will spend my weekend on, I will watch your repo for the update ;-)

Have you drawn these sprites yourself? This looks great and I love the modulo addition which I think will make this a lot harder for me actually.

Dröm Sött, indeed! :-D

[mewmew]

I think this might be what I will spend my weekend on, I will watch your repo for the update ;-)

❤️

The mod is now go-getable at https://github.com/mewbak/bubble-blaster

Have a great weekend!

Cheers,
Rex and Robin

[gonutz]

Regarding my previous comment about DirectX shaders and fxc.exe: I found out that you CAN actually compile shaders from source on Windows, there is a DLL called D3DCompiler_XX.dll (XX being two version digits) and I have created a wrapper for it in Go. This DLL seems to come with all Windows as well, my fresh XP VM has it already and I guess Windows 10 has it too (have not confirmed that yet, though).

This means that eventually we can have the user write HLSL code similarly to the GLSL API. Additionally we can have the option to use compiled DX shaders as well.

As I said, this is at the bottom of my TODO list, I am still working on getting the basic functionality ported.