next »

[eddietree]

The combination of the artwork, sound and music makes this really beautiful. Keeping an eye on this.

Thanks

If I had to nitpick, the water splashes seem perpendicular to the screen. They need to be skewed a bit.

Yea, I know the water is kind of shit right now. The problem is that I want to create some sort of perspective plane on the water surface. To "fake" that effect, I currently have it such that "distant" pixels have a smaller expansion rate than nearby pixels. I fixed it now so that the splash radius is smaller into the distance. Hopefully that makes the perspective seem a bit more believable. Thanks for the tip!


Also, shout out to my Japan homeboy Tatsuma Murase, who secretly spies on this thread.

[eddietree]

Sort of unrelated, but for those who are attending to GDC San Francisco next week, please check out this thread. Some of the PixelJunk crew and I will be at the event to pimp our soon-to-launch title, Pixeljunk 4am.

Here is one of the flyers:

[eddietree]

Any game designers out there interested in joining this project?

The Kyoto dev team is planning something big and would love to have an awesome game designer help out with project.  If you are interested, please shoot me an email: [email protected].

[Franklin's Ghost]

If I was actually a better game designer then I am, I would totally jump on this chance. Love your project and think it's a great opportunity for anyone who can help. Good luck finding someone 

[Dugan]

Sort of unrelated, but for those who are attending to GDC San Francisco next week, please check out this thread. Some of the PixelJunk crew and I will be at the event to pimp our soon-to-launch title, Pixeljunk 4am.

Here is one of the flyers:

great flyer - is that from a screenshot? Its like tron meets 2001

[stef1a]

Stopping by to say that this looks amazing, and that I really like the Japanese influence. 

[eddietree]

]
great flyer - is that from a screenshot? Its like tron meets 2001

Thanks! Yes all the posters are made directly from screenshots of the game.


Anyhow, now that I'm back from Gdc, I hope to get back into the swing of things. Will post updates as they roll in.

Cheers all!

[eddietree]

I have been kind of quiet lately, sorry. I have been quite busy with work and whatnot. But now I am back on the dev wagon!

So in this update, I finally stopped being a pussy and decided to take the weekend to code up an immediate mode GUI system. For those of you who are looking to implement an in-engine development GUI, really look no further, because immediate mode allows you to quickly prototype a gui system without having to deal with delegates/function pointers bullshit that traditional gui systems require.


For example, in my update loop if I call this code..

Code:

void Update()
{
	Imgui::Begin("TITLE");
	if ( Imgui::ButtonPress("Press me!") )
	{
		// do something
	}
	if ( Imgui::ButtonPress("Press me too!") )
	{
		// do something else
	}
	Imgui::SliderFloat( "Floater", fval, min, max );
	Imgui::TextLine("Text Here", testStr );
	Imgui::CheckBox("Checkbox", enabled );
	Imgui::End();
}

I get this displayed on screen:



And if I don't want that GUI to show, I just don't call that code. No more creating objects and dealing with instantiation and pointers. Everything just works and now development should be smooth sailing (maybe).

Features that my immediate gui system currently supports:

• buttons
• sliders (float/int/float3/color)
• checkbox
• textbox
• selection (radio)
• dragging/minimizing windows

Here is another screenshot of me testing my gui system..


(More info here about immediate mode guis.)

[offset]

Totally awesome! Errrm.. open-source? 

[BlueSweatshirt]

Also I am the project's game designer. 

[SiENcE]

I have been kind of quiet lately, sorry. I have been quite busy with work and whatnot. But now I am back on the dev wagon!

So in this update, I finally stopped being a pussy and decided to take the weekend to code up an immediate mode GUI system.

Yep, IM-GUIs are great stuff. This is the IM-GUI i use https://github.com/vrld/Quickie . It's for LÖVE.

[eddietree]

Yep, IM-GUIs are great stuff. This is the IM-GUI i use https://github.com/vrld/Quickie . It's for LÖVE.

Thanks for the link! Yes, I've seen the LÖVE implementation before and it is quite nice. My engine has my immgui workin on the C++ end as well as in my GameMonkey scripting language.  GUI systems really have improved my productivity so the investment was well worth it.

The biggest difference between my version and LÖVE's implementation is that in LÖVE's immgui system, each time a widget is called the draw call is pushed into a command list, which allows you to separate the immgui's Update function from the Render call, which has it's advantages and disadvantages. My version is not that modular (the GUI function is called in the render), because I really am trying to focus on simplicity, but the downside is my GUI is heavily tangled up in the render call, which can be bad.

The problem with having it modular like LÖVE is that whenever you need to implement a new GUI widget with a specific draw style (i.e. not simply squares or text), you not only have the implement the widget but also the render queue command as well as the render command. So adding new widgets become sort of a pain. Thus, it really depends on how much time you want to waste on the gui system.

Anyhow, thanks again for the response! 

[BlueSweatshirt]

In my little IMGUI system I have widgets draw to a buffer, then the draw is called in the render loop by the ui context. Best of both worlds approach imo.

[eddietree]

In my little IMGUI system I have widgets draw to a buffer, then the draw is called in the render loop by the ui context. Best of both worlds approach imo.

Jack: Maybe I am not understanding you fully, but in order to draw widgets to a buffer like you mentioned, you have to bind a render target; and if every time you draw a gui window you have a bind a render target, this will GREATLY slow down performance on the GPU. Setting render targets is one of the slowest operations in OpenGL/Dx architecture, as it ofentimes requires a full flush of the GPU pipeline. That it because triangles and pixels that are pushed in the pipeline must be fully calculated (shaded) and rasterized onto the current surface in order to switch to a new one.

So in your method, to draw a simple GUI, requiring a potential flush stall on the GPU is not very efficient. I would recommend you avoid any "draw to buffer" operations if needed.

Either way, it still doesn't solve the problem of decoupling the render from the update, it just greatly slows down performance. But if you are going to do it this way, it might be better to just cachethe function pointers of the render functions and just call the function towards the end of the frame (so that it is on top of everything).

[harkme]

Beautiful work! I'm currently fascinated by shader programs, so this is quite juicy. I also like the way the grass and tree sway.

However, my performance is pretty bad. It goes around 11-15FPS:


My specs are as follows:
CPU: Intel i7-980x @ stock speed
GPU: HD 5870 1GB
RAM: 6GBs

I'm using the 11.11a catalyst drivers from AMD and running on Windows 7 64-bit.

[eddietree]

Beautiful work! I'm currently fascinated by shader programs, so this is quite juicy. I also like the way the grass and tree sway.

However, my performance is pretty bad. It goes around 11-15FPS:


My specs are as follows:
CPU: Intel i7-980x @ stock speed
GPU: HD 5870 1GB
RAM: 6GBs

I'm using the 11.11a catalyst drivers from AMD and running on Windows 7 64-bit.

Thanks for your posting your spces and framerate! Yes, I know the rendering is a bit slow and I have many plans for optimizing. I think now the bottleneck is definitely GPU fillrate.  But stay tuned, I will get that number to 60hz!

[BlueSweatshirt]

Jack: Maybe I am not understanding you fully, but in order to draw widgets to a buffer like you mentioned, you have to bind a render target; and if every time you draw a gui window you have a bind a render target, this will GREATLY slow down performance[... snip]

Oooh, awesome, thanks!
I hadn't considered that.
However thankfully for me, mine is for use with a bitmap-based game library so I don't think there's much overhead being added--I should check that out.

[eddietree]

Oooh, awesome, thanks!
I hadn't considered that.
However thankfully for me, mine is for use with a bitmap-based game library so I don't think there's much overhead being added--I should check that out.

Don't mean to beat a dead horse, but if the bitmap-based game library is using the GPU, there will be a problem. And I assume that any modern game library will use GPU hardware acceleration. Perhaps your game just isn't very graphic-intensive so you cannot notice any slowdowns. Have you profiled the GPU to see how long it takes?

[eddietree]

Aw yeah, implemented an in-game particle editor. This is my first good use of my immediate-gui system. Now, I can quickly mockup fresh particles systems as well as being able to quickly iterate on them. The particle editor supports basic 2d particle settings, such as:

• Emitter cooldowns and particle lifespans
• Spawn position
• Spawn angle
• Velocity & acceleration
• Rotation and rotational velocity/accel
• Color and blending functions
• Texture support

[eddietree]

Trying out a few different color schemes. Would love to know what you think!