Thanks
That last gif looked good, but I'm actually still having issues with it...
Note the blocky shadow in the doorway, and also the strange glitch in the shadow on the right hand wall. I think I can fix the wall bug, but doubt there's anything I can do about the blocky floor shadows
However, while the old gif used a really buggy system with a separate shader for the wall shadows (which wouldn't have really worked in an actual game), I've now combined both wall and floor shadows into a single shader, so that's a *big* improvement
Hayo, if you decide you do have some time for freelancing at that point, mind giving a hoot on the emails? I'll trade wallet liners for a smidge of art.
Sketchy, that looks really awesome! But at this point wouldn't it be easier to just code it straight in MMF?
Also, what parameters is the shader using that it knows the room layout?
Anyway, lately I've been fiddling with the idea of an object-based engine. Right now it's really rudimentary:
The idea is that a character will stick to an object once it's collided, and collide with/stick to other objects if it intersects them as well. And the character will be able to tell what kind of slope it's standing on or what angle it's passing over, so that if something is too steep or too acute it will collide or else detach from the object and return to a free-moving state (not shown here).
This character has no slope limitations, so it just clings to things forever. You can probably tell it's not perfect, but I think it has promise. I can't wait to start making levels with massive spinning obstacles.
Originally Posted by Fifth Sketchy, that looks really awesome! But at this point wouldn't it be easier to just code it straight in MMF?
Also, what parameters is the shader using that it knows the room layout?
Thanks
The idea of using a shader is to improve performance, by shifting all the complicated calculations to the graphics card (plus I've already done it using the Surface object before). In practice though, there are three problems:
1.) It's very difficult to make a shader that works perfectly, without any kind of glitches (as you can see).
2.) Raycasting (possible in a shader) is a lot less efficient than shadowcasting (not possible in a shader).
3.) The specific method of raycasting that is possible in a shader is particularly inefficient (it re-visits the same pixels repeatedly).
Anyway, the way it works is that each light source is a separate object, containing a map of the level. White means clear - anything else will block light rays. Black pixels are always dark. Intermediate shades of grey are used for the walls that are able to be illuminated - the lightness represents the vertical distance from the pixel, to the base of the wall - and then to find if the wall should be illuminated or not, the engine traces a line from that point at the base of the wall, to the lightsource.
I think it's quite a neat solution, and it requires virtually no extra calculations.
I could very easily (and probably will) use two separate components (ie. red & green) to give me both horizontal and vertical offsets, so that the system would work equally well with walls facing other directions - eg. isometric walls.
btw: Nice engine - reminds me of one of Pixelthief's old projects. You'll find it's when you add gravity and jumping that it starts to get complicated...
No posts for a while.. I guess everyone feels intimidated by Fifth and Sketchy's awesome engines! But I don't want Clubby to come here and see nothing but forum spam, so..
I've been working on a new game recently. It's an arcade arena platformer game and I had a lot of fun making it. I wanted to make something colourful after Falafel, and to make the music myself this time. It's almost done and I'm putting in finishing touches now, and stuff I always stupidly leave until the end like joypad controls. Here's a wee video of it so far:
Looks like a simple and fun kind of minigame. Nice to see someone else is still around here occasionally too...
As you can probably tell from this thread alone, I have the world's shortest attention span, so since my last post I've been working on all sorts of different things...
I made a 3D Look-Up Table (LUT) pixel shader for someone on the Clickteam forums, which is used to perform pre-defined color adjustments - perfect for day/night/weather effects, and probably other things too.
I started working on a kind of squad-level roguelike, partly inspired by MicRogue and X-Com - and as part of that, I made a very simple extension-less pathfinding system (an implementation of Dijkstra's algorithm), and also remade an old procedural level generation system.
I'm working on a new array editor, using a combination of MMF2 and Javascript (via the WebControl extension). Unlike my previous array converter, this one actually has a spreadsheet-like interface. It won't support xml any more, but it will support 3d arrays via multiple csv files, and via json files (including "Tiled" map files and "Construct 2" arrays). Also, it should allow scripting via Javascript (a bit like using macros in Excel), which could be used for things like auto-tiling.
I wrote a Javascript library to add some features from Clickteam products, such as event-based programming, automatic object pairing, object scoping, etc.
To go along with that, I created my own scripting language, and a compiler to turn code written in this language, into Javascript that uses the new library I wrote. The next step would be to create a basic HTML5 game engine to work with the new language.
I'm still looking to move away from MMF2 / CF2.5 altogether, and have started to explore other options, including Construct 2 and Unity 3D. I've pretty much reached the conclusion now that my best is probably to just create my own simple HTML5 game engine instead...
Mostly though, I'm busy with actual work and looking for a job for the winter...
Huh? Didn't understand a word of that!
It's generating Javascript, not Java, so it doesn't involve any bytecode:
^ On the left is the original code; on the right is the Javascript that is generated from it (in the middle are all the individual tokens from the lexer). All those functions you see (newEvent, newObject, setProperty, etc) are part of the new library that I wrote.
This is the 3d LUT shader in action:
At the bottom you can see what are effectively two palette images, know as "Look Up Tables" (LUTs). Basically, what the shader does is to replace the colors in the first palette, with the colors at the same position in the second palette. In this example, the red, green and blue components vary in increments of 15, giving a total of 4913 unique colors - but the clever part is that for any colors which appear in the image but aren't in the palette (if any component is not a multiple of 15), the shader uses linear interpolation to calculate what the output color should be, so the resulting image isn't limited to 4913 colors. You can of course, use larger LUTs for better accuracy. It's quite a handy shader, because it essentially lets you adjust red/green/blue/hue/saturation/brightness/gamma etc curves, all at once.
Link: http://community.clickteam.com/threads/98225-REQUEST-3D-LUT-Shader?p=700768&viewfull=1#post700768
This is the array editor so far:
It was actually quite a mission just to get everything to adjust properly when the window is resized. The tabs along the top are to set the array Z-axis; the rest should be pretty obvious.
Finally, just a few of the many weapons from my squad-level roguelike:
These images sort of demonstrate one of the game's core mechanics - that combat is completely predictable; there is no element of luck whatsoever. Units will get 2 actions per turn. Moving costs 1 action, and other things like firing weapons and using items may also use 1-2 actions. Ammunition is also extremely limited, so it's important not to waste it.
If you look at the Assault Rifle, you can see that its "semi auto" firing mode uses 3 rounds of ammo and 1 action point, but does 2 points of damage - so in a whole turn, it could inflict up to 4 points of damage (but would use 6 rounds of ammo in doing so).
On the other hand, the Sniper Rifle's "aimed" firing mode also does 2 points of damage, but only uses 1 round of ammo - the trade off is that it costs 2 actions (ie. it takes a whole turn), so the weapon is capable of inflicting less total damage per turn (note that both weapons also have a "snap" firing mode, which is a compromise between the two). Consequently, you would want to conserve ammunition by using the sniper rifle to pick off targets from a distance, and use the assault rifle to take down more heavily armored targets.
Also shown is the Plasma Rifle, which doesn't require ammo, but has to recharge after each shot, which seriously limits its ability to keep inflicting damage turn after turn - not good if there are a lot of enemies around.
I'm still working on this. It's obviously way different and I abandoned it for awhile. Most probably won't remember the first project of it. Anyways for once I am making progress enough to be motivated and somewhat proud of myself.
I'm still working on this. It's obviously way different and I abandoned it for awhile. Most probably won't remember the first project of it. Anyways for once I am making progress enough to be motivated and somewhat proud of myself.
Advertisement
Post Reply
Edited by Sketchy
