What's kind of this technology such as moving pixels?

Discuss game development design and post your game ideas

Post » Wed Jun 03, 2015 12:15 am

The loading bar reminds me of the akihabara engine.
http://www.kesiev.com/akihabara/
Providence University, lecturer.

Tatung University, lecturer.



Consultant per question: USD$15 / time

Consultant by month: USD$300 / month

Customized project: USD$2500 / capx
B
78
S
16
G
4
Posts: 196
Reputation: 7,688

Post » Mon Jun 29, 2015 4:56 am

R0J0hound wrote:Looking at the source it uses a pixel array of the canvas and set's pixels individually for all drawing. It doesn't use any of the higher level stuff such as drawImage like most other games in html5 uses. In that regard it's very different than C2. The advantage is it can do those oldschool pixel effects like old dos games, for example the level transition and the dripping blood. Also do to it being low res without any scaling or rotation, per-pixel collisions can be used everywhere. The disadvantage is it has to be low res to keep up the performance, and there is no rotations or scaling of the sprites. Also no doubt they do a lot of tricks to keep things as fast as possible.

What I got out of it that we might be able to use in C2 is a way to access pixels individually. The canvas kind of does this but things are inefficient. Basically reading pixels is pretty slow but it's much faster to write pixels, although it's probably not compatible with html5's other drawing methods. So maybe a plugin that allows you to manipulate an array of pixels that you can then copy to a texture. Only if events had zero overhead would it perform as well.


I've always loved the colour cycling effect http://www.effectgames.com/effect/artic ... HTML5.html
The author talks about accessing a pixel array, so I guess the implementation is similar to this game?
B
19
S
4
G
4
Posts: 67
Reputation: 3,181

Post » Mon Jun 29, 2015 11:18 am

It's possible to do something similar with construct 2, for example when bullet hit the ennemies, it spawn red square sprites with physics behavior and apply "impulse toward angle" with parameter "bullet.angle-(180-random(your values))".

When this blood sprite hit the ground, you can keep it physics and being able to see the blood move under your feets, or it automatically spawn none physics red sprite on collision, and finally for the blood flow effects, this sprite check if he is overlapping with another instance, if it does it move down on vertical axis till condition become untrue.

I don't know if i was very clear but i could do a .capx example if you like. It's still an unperfect alternative, but it's quite effective if you're not looking for the exact same pixel technology.
B
8
S
1
Posts: 38
Reputation: 542

Post » Mon Jun 29, 2015 3:01 pm

@BlueSkies
Yeah it's the same way to access pixels.

@Logomachine
Physics would work in concept, but in practice it would be much too slow. A manual per-pixel motion as you describe would be a bit faster, but you'd need to implement most of it in js to get a useable speed.
B
92
S
32
G
106
Posts: 5,272
Reputation: 69,455

Post » Mon Jun 29, 2015 7:03 pm

R0J0hound wrote:@BlueSkies
Yeah it's the same way to access pixels.

@Logomachine
Physics would work in concept, but in practice it would be much too slow. A manual per-pixel motion as you describe would be a bit faster, but you'd need to implement most of it in js to get a useable speed.


You're right, it's CPU expensive, I tryed and i fall to 20FPS with ~500 sprite sized to 8x8 pixels on ground and wall.
Do you think get the position of the overlapping blood sprite, write his color to the ground/wall sprite, then destroy his instance would be effective?
Or does in engine like construct 2, run a plugin is the only way to get this result without killing the framerate?
B
8
S
1
Posts: 38
Reputation: 542

Post » Mon Jun 29, 2015 8:35 pm

Logomachine wrote:
R0J0hound wrote:@BlueSkies
Yeah it's the same way to access pixels.

@Logomachine
Physics would work in concept, but in practice it would be much too slow. A manual per-pixel motion as you describe would be a bit faster, but you'd need to implement most of it in js to get a useable speed.


You're right, it's CPU expensive, I tryed and i fall to 20FPS with ~500 sprite sized to 8x8 pixels on ground and wall.
Do you think get the position of the overlapping blood sprite, write his color to the ground/wall sprite, then destroy his instance would be effective?
Or does in engine like construct 2, run a plugin is the only way to get this result without killing the framerate?


This is one of those times where C2 is actually too complicated to solve the problem, there's too much code bloat in using a game engine to do something so low level.
B
59
S
21
G
9
Posts: 641
Reputation: 9,787

Post » Mon Jun 29, 2015 8:59 pm

Elliott wrote:
Logomachine wrote:
R0J0hound wrote:@BlueSkies
Yeah it's the same way to access pixels.

@Logomachine
Physics would work in concept, but in practice it would be much too slow. A manual per-pixel motion as you describe would be a bit faster, but you'd need to implement most of it in js to get a useable speed.


You're right, it's CPU expensive, I tryed and i fall to 20FPS with ~500 sprite sized to 8x8 pixels on ground and wall.
Do you think get the position of the overlapping blood sprite, write his color to the ground/wall sprite, then destroy his instance would be effective?
Or does in engine like construct 2, run a plugin is the only way to get this result without killing the framerate?


This is one of those times where C2 is actually too complicated to solve the problem, there's too much code bloat in using a game engine to do something so low level.

All right, thanks for answering. ;)
B
8
S
1
Posts: 38
Reputation: 542

Post » Mon Jun 29, 2015 9:22 pm

@Logomachine
You could draw those sprites to the "paster" or "canvas" plugins, and then destroy the sprites to reduce the number of objects. The physics behavior itself has more features that we need. Basically we only need a simpler physics for the particles and a per-pixel collision detection. Such collision detection isn't compatible with polygon collisions, so all motion would need to be done via events. Drawing to the terrain is doable as stated above, but with a huge amount of moving pixels it would be faster setting pixels directly rather than using sprites and such which is faster for larger objects.
Lastly to get the utmost speed js should be used instead of the event sheet.

@Elliott
It's the type of game that needs as much optimization as possible and C2's general purpose nature isn't efficient for it. It does stuff like per-pixel collisions, and reading and writing pixels which C2 doesn't do because such features, even when optimized are only usable for low-res games.
B
92
S
32
G
106
Posts: 5,272
Reputation: 69,455

Post » Tue Jun 30, 2015 1:47 am

Hello world (it's my first post here)!

I'm responsible for Butcher's programming (and for a few other things, but that's unrelated now). We (THD) have received an email asking for explanation of how the game works, so I hope I'll provide you enough info about it.

  1. I haven't used any external engine, it's a custom JavaScript (it started as a simple experiment/exploration of canvas capabilities). It has its good and bad sides. The bad side is that some parts definitely could be coded in a more elegant way, but overall it was a cool experience.
  2. I haven't used WebGL (besides pixelation/stretching the screen, which seems to be faster if done with WebGL shader - the rest is fully software/canvas and you can play without WebGL support)
  3. The burning logo, the rain of blood in the intro and the lava effects (including lava particles - they repeat after a while) are just color-cycled images, this part was partly inspired by Canvas Cycle demo, although the implementation and functionality is a little different (simpler I think):

    1. The palette is a strip of colors that will appear in the output image, including transparent colors.
    2. The input image is completely grayscale, each pixel represents a different place on the palette, shifted by a time variable (and also looped, so it can cycle)
    3. I obviously read the input image once, then just put pixels repeatedly at the runtime.
    I must admit I did that thing mainly because of my nostalgia (some games used palette cycle technique in the past), I don't know yet whether that approach is useful or not (in comparison to normal animations), but it has some advantages (for example, creating organic animations like fluids or burning seems to be easier that way). R0J0hound was right that the canvas implementation requires low-res for good performance, but a pixel shader doing the same thing on much bigger textures could be very fast (it'd require only 2 texture reads after all).
  4. The collision is based on internal array to avoid reading pixels. The level was even initially destructible in some areas, but we got rid of it as it didn't work out well for this type of gameplay. The collision masks are also pre-processed to avoid too awkward logic at the runtime (and also to make the movement smoother). For example, I detect slopes to simplify the platformer collision code.
  5. I do use drawImage() a lot like other games, because that's the fastest method of drawing bigger sprites, also the game supports rotation and scale (saws, bullets, some particles), it's just not used that much because of the style we were aiming for. However, the level is indeed painted per-pixel because of the internally stored collision mask. I need to paint both the mask (i.e., the array) and the image, so the easiest way is just to paint pixels (one by one) of both at the same time (because I don't have any high level function to paint arrays :P). It's definitely slower than using drawImage(), but the sprites painted on the level are very small (4x4 pixels max. I think), so it shouldn't hurt that much. The fastest and most flexible method of painting blood (and in general pixels that were potentially spread everywhere) was to draw filled 1x1px rectangles (because you don't want to draw 400x400 pixels just to draw 5 blood pixels and you don't have to create image data each blood pixel), at least that was what jsPerf test told me back then.
  6. I use my own matrix stack and matrix operations, because it seems to be faster than save()/restore() on modern PCs/browsers. I think it squeezed out a 0.5 ms or so, not that much, but it was just kind of a mental masturbation to fiddle with it.
  7. I use an extremely simple space division algorithm (I just divide the whole level to a "buckets" and put things in proper buckets according to their positions), it could support 1000 of self colliding squares spread throughout the whole level at 60fps on my computer, afair the drawing of the rectangles was a bottleneck here, so I considered it good enough for my case.
  8. The Doom effect is just a bunch od drawImage() calls (each strip is a different call).
  9. The game could run pretty smoothly on computers from 2007+, but the bottleneck on the older graphic cards was, surprisingly, stretching the whole canvas aka pixelation. The game was playable if played in its native resolution (320x180, yes, it's 16:9 :D), it started to lose frames if you tried to stretch the screen to enlarge in-game pixels. Also, the modern browsers didn't want to support the WebGL pixelation on older cards, Chrome even blacklisted some chipsets. Oh well. That's one of the reasons I now develop the game on a different platform (I don't develop my own engine this time, I decided to use Unity - now I regret a little, because it's still not a perfect engine for that kind of game, but at least the new Butcher runs smoothly on older PCs).
  10. Standalone versions are built with node-webkit.

I think that's all for now, ask me if you want to know further details. I've originally tried to post some links, but I can't do it (the posts just didn't appear, no messages, no anything, I think it's a bug in the forums script - even if newcomers can't post links, I'd expect some validation messages).
B
2
Posts: 8
Reputation: 156

Post » Tue Jun 30, 2015 2:49 am

@smk
Thanks for the detailed write up. I always enjoy reading about that kind of low level stuff, and I could only gather so much from skimmed through the source. To post links, I've seen newcomers putting then inside [code] tags and the forum doesn't erase them.

@spongehammer
@Logomachine
I was toying with a way to access pixels to see how fast it could be from construct and here's a working test:
https://dl.dropboxusercontent.com/u/542 ... eData.capx
It's fast but only when using js.
With a 160x120 image, updating all the pixels took an average of 12 ms on my machine. For 60fps that plus everything else needs to be 16ms or less.
The event system on the other hand was way to slow to loop over the pixels. I actually just looped over a 160x120 array to set each xy to a random number and got an average of 230 ms.
B
92
S
32
G
106
Posts: 5,272
Reputation: 69,455

PreviousNext

Return to Game Development, Design & Ideas

Who is online

Users browsing this forum: No registered users and 0 guests