[video=youtube;HQe0LJgknH4]http://www.youtube.com/watch?v=HQe0LJgknH4[/video]
verlet + particle engine = fun
lots of optimisation to be done but overall I'm quite happy ;p
Underlines prefixing things? Its GM9 all over again
[QUOTE=Map in a box;32066937]Underlines prefixing things? Its GM9 all over again[/QUOTE]
No, that's a specific convention I used for only the variables _CLIENT and _GAME which are the Lua end of replicating the purpose of CLIENT_DLL and GAME_DLL respectively. It's a defined variable which should never change. Everything else is normally defined. engine.IsPaused(), networkstringtable.GetTable(), etc.
This convention just conforms to what Lua does with _VERSION.
So how long until a spawn menu? :v:
Henry (the dudeski who wrote HAT, or Henry's Animation Tool, for GMod) wrote a spawn menu on his branch of the game code, but we may not be using it, or only some of the code.
I plan on having something like a prop-band which slides in from the side of the screen. I'd like to divert from what's seen in GMod and create something fresh. One big concept I'm juggling is the idea of using city scanners as a way of "no-clipping" while you move around props, instead of using the Physics Gun.
We have a lot of code reworked for the Physics Gun, which is a heavily modified multiplayer variant of Valve's old code which now includes predicted code [url=http://code.google.com/p/hl2sb-src/#Proudly_powered_by](also features ARGG code),[/url] but like I said, we may not even use this, and go for an entirely different approach. If we end up using the Physics Gun, (which we call the Prototype Physics Manipulator), it'll be something different from what you see in Garry's Mod. Mainly in the effects department.
[editline]1st September 2011[/editline]
[hd]http://www.youtube.com/watch?v=mVjchSzoZzk&feature=BFa&list=PL7942161CD7245129&lf=mh_lolz[/hd]
[editline]1st September 2011[/editline]
His branch doesn't show any effects at all for some strange reason. I'm not sure why.
Decided to re-implement the engine (going multi-threaded).
[IMG]http://localhostr.com/files/OLuHfoL/capture.png[/IMG]
I lost power for four days during the hurricane, so I made a virtual enigma machine on my netbook.
[code]
require 'enigma.rb'
e = Enigma.new [Rotor.new, Rotor.new, Rotor.new]
e.set 24, 3, 16
e.code "SECRETCODE" # returns "ETLCZCXLYV"
e.set 24, 3, 16
e.code "ETLCZCXLYV" # returns "SECRETCODE"
[/code]
You can swap out rotors, change the reflector, add and remove plugs, etc. It also includes what is probably the greatest method I have ever written:
[code]def remove plug
if @plug[plug] == plug
puts "There is no plug in #{plug}."
else
@plug[@plug[plug]] = @plug[plug]
@plug[plug] = plug
end
end[/code]
very self-documenting code
Some fun with wireframe.
[IMG_thumb]http://img190.imageshack.us/img190/5444/bvhstencil31811.png[/img_thumb]
Light volumes are intentionally scaled way down so you can see how they work. I've got separate bounding volume hierarchies for models and lights which aid in frustum culling. Lights are rendered in two passes (per light) -- an initial stencil-only pass using bounding geometry, then the actual lighting pass as a full-screen quad.
The teal and purple spheres are bounds for individual lights, the orange sphere is the parent node in the tree.
And a final image with both point lights, ambient, directional, and emissive:
[img_thumb]http://img849.imageshack.us/img849/8766/31811.png[/img_thumb]
I'm playing around with SSAO but, sadly, I don't think my craptastic laptop (or 'craptop' for short) is going to cut it.
[editline]2nd September 2011[/editline]
I really need to get an obj loader up and running so I can test with that awesome sponza model, but I loathe parsing plaintext formats...
[QUOTE=ROBO_DONUT;32068439]-snip-but I loathe parsing plaintext formats...[/QUOTE]
You'll totally LOVE collada then!
[QUOTE=ROBO_DONUT;32068439]Lights are rendered in two passes (per light) -- an initial stencil-only pass using bounding geometry, then the actual lighting pass as a full-screen quad.[/QUOTE]
Doesn't that give the same result as if you were to do it in one pass?
Craaaazy.
[t]http://i.imgur.com/tOh2m.png[/t]
(And sadly that's all the joypads I got, so no 8 player screenshots from me)
[editline].[/editline]
Gotta change the particle color of portals too.
Done! I don't feel like redoing the screenshot though.
[img]http://i.imgur.com/z5xl3.png[/img]
I'm so happy I'm getting shit done again. It's like writers block except for coding.
Do you have multiplayer support yet(networked)? I'd imagine it be quite easy if you already have multiple joystick/controller support
[QUOTE=Maurice;32069581]Craaaazy.
[t]http://i.imgur.com/tOh2m.png[/t]
(And sadly that's all the joypads I got, so no 8 player screenshots from me)[/QUOTE]
Have you thought about just using the Mario cast (Mario, Luigi, Peach, etc.) and coloring the portals based on that person?
Like...
Mario - Red & Orange
Luigi - Green & Dark Green
Peach - Pink & White
I'm not sure what you'd use for a 4th character...
Just throwing that idea out there.
Mmmm java 7:
Enhanced library-level support for new network protocols, including SCTP and Sockets Direct Protocol
and java 8:
lambdas(only going to be slightly late in the lambda times for release at oct 2012)
[url]http://en.wikipedia.org/wiki/Java_version_history#Java_SE_7_.28July_28.2C_2011.29[/url]
So I had an idea, not sure how awesome or stupid it is, that's why I'm asking some opinions.
In a voxel (or pixel) based game would it be a good idea to mimic the behavior of an octree in the context of slicing an object apart. Take a cube for example:
1. The cube is static.
2. Draw a line through the cube (or swing a sword, slam an axe, penetrate with bullet)
3. Subdivide the cube to a certain depth (depending on the complexity of the desired outcome)
4. Replace the previous cube with a new set of cubes based on the subdivisions, so the larger and unsliced nodes remain unaffected and static, but the smaller nodes, within a certain distance from the line, become smaller cubes with physics implemented, so they scatter away.
5. Scattered smaller nodes could either become static for a certain amount of time as the integrate with ground and become their own parent node ( which could theoretically be subdivided further in the same way ( possibly running a check to see if it's within a reasonable size ) ), or they could disappear after some time so as to not my the physics of the engine impossible to use.
Thoughts?
[QUOTE=Philly c;32069257]Doesn't that give the same result as if you were to do it in one pass?[/QUOTE]
Maybe visually, but not performance-wise.
If you render lights as a full-screen quad without stenciling, you have to do potentially expensive lighting calculations for literally millions of pixels for each and every light. If you skip the stencil pass, rendering lights as bounding geometry and use a simple 'greater than' depth test, you still end up with overdraw from geometry far in front of lights. Also, if you render lights as bounding geometry in one pass, you're forced to use expensive matrix operations to extract per-pixel eye/world coordinates. If you use a fullscreen quad, you can create perspective rays as a vertex attribute and project screen-space to eye/world space in a single MAD instruction.
So:
1. Stencil pre-pass using bounding volumes: eliminates all overdraw
2. Full-screen quad lighting: simplifies screen to eye/world-space calculations
Also, this allows for spot-lights, just replace the sphere with a cone or w/e.
[QUOTE=NorthernGate;32069841]So I had an idea, not sure how awesome or stupid it is, that's why I'm asking some opinions.
In a voxel (or pixel) based game would it be a good idea to mimic the behavior of an octree in the context of slicing an object apart. Take a cube for example:
1. The cube is static.
2. Draw a line through the cube (or swing a sword, slam an axe, penetrate with bullet)
3. Subdivide the cube to a certain depth (depending on the complexity of the desired outcome)
4. Replace the previous cube with a new set of cubes based on the subdivisions, so the larger and unsliced nodes remain unaffected and static, but the smaller nodes, within a certain distance from the line, become smaller cubes with physics implemented, so they scatter away.
5. Scattered smaller nodes could either become static for a certain amount of time as the integrate with ground and become their own parent node ( which could theoretically be subdivided further in the same way ( possibly running a check to see if it's within a reasonable size ) ), or they could disappear after some time so as to not my the physics of the engine impossible to use.
Thoughts?[/QUOTE]
Afaik its used in destructible terrain.
[QUOTE=Map in a box;32070048]Afaik its used in destructible terrain.[/QUOTE]
Thought about that but wasn't sure if that kind of destructable terrain was just a bunch of small voxels that were removed on impact instead of larger voxels being subdivided into variable sized voxels.
Never seen those turned into physics objects though, so idk.
[QUOTE=NorthernGate;32070084]Thought about that but wasn't sure if that kind of destructable terrain was just a bunch of small voxels that were removed on impact instead of larger voxels being subdivided into variable sized voxels.
Never seen those turned into physics objects though, so idk.[/QUOTE]
It would be way faster to have it start with the larger and divide down to the smaller.
Less slow, but neither are very fast.
Also, look what my game can do now:
[img]http://img690.imageshack.us/img690/508/pauses.png[/img]
[QUOTE=chimitos;32070251]It would be way faster to have it start with the larger and divide down to the smaller.
Less slow, but neither are very fast.
Also, look what my game can do now:
[img]http://img690.imageshack.us/img690/508/pauses.png[/img][/QUOTE]
I remember your game being called Neon something, right? In that case, you should add more glow to the shapes.
More like this maybe:
[img]http://i.imgur.com/BPpeT.png[/img]
(That looked better in my head, but I still think it's an improvement)
[QUOTE=ROBO_DONUT;32069987]If you skip the stencil pass, rendering lights as bounding geometry and use a simple 'greater than' depth test, you still end up with overdraw from geometry far in front of lights.[/QUOTE]
That's what I meant, and that makes sense, but i've gotta say, I still don't understand how using the stencil buffer gets around this.
I think I'm going to start working on a 3D game. Any suggestions for level formats?
[QUOTE=Philly c;32070620]That's what I meant, and that makes sense, but i've gotta say, I still don't understand how using the stencil buffer gets around this.[/QUOTE]
Render both front and back faces using a 'greater than' depth test, toggling the stencil whenever it passes. Because the front and back faces cancel out for geometry outside the bounding volume (where both pass or both fail the depth test), only geometry inside results in a non-zero stencil value.
getting the sprite to rotate and still look ok is hard...
[img]http://img855.imageshack.us/img855/2064/question2.png[/img]
better?
[QUOTE=chimitos;32070913]getting the sprite to rotate and still look ok is hard...
[img]http://img855.imageshack.us/img855/2064/question2.png[/img]
better?[/QUOTE]
Circles yes. triangle not so much.
[QUOTE=chimitos;32070251]It would be way faster to have it start with the larger and divide down to the smaller.
Less slow, but neither are very fast.
Also, look what my game can do now:
[img]http://img690.imageshack.us/img690/508/pauses.png[/img][/QUOTE]
In my opinion, I kinda like that small glow to it. It's not too much.
I love this FP web app, makes replying to WAYWO so easy I don't have to get out of bed! :D
A have a bit of trouble with my latest project.
So, I was annoyed that you can't tell dropbox to sync a folder outside of his own folder and then I learned about links (symbolic, hard and directory junctions) and set off to make a program that would allow me to right click -> Sync with Dropbox on any file or folder.
First I had to determine if the path that is given to the program points to a folder or a file (since for some reason you can't use hard links on folders or junctions on files...) and then using some hacky magic I made it work. Or so I thought.
The files work fine. I hard link any file and it syncs with dropbox, and when I change it it syncs again but folders just don't want to play nice.
I make a junction to a folder and it syncs fine and all the files in the folder are also uploaded but for some reason it just doesn't notice when I change a file in that folder or add/remove one. I tried using symbolic links for folders but it doesn't change anything.
Any ideas?
Sorry, you need to Log In to post a reply to this thread.