I’ve posted my game on the concepts section in Steam Greenlight to see what kind of buzz the game in it’s current state generates, if you guys could head on over there and help it out with a thumbs up you would be doing me a great service.
It’s just the concept section on Greenlight, it’s not the actual Greenlight area. The votes are meaningless (and honestly the section is largely ignored). I just wanted to see what kind of feedback I would get from non-dev types. Reason I was asking for help is so I could keep it on the “popular” lists so people actually see it. The concept section is just a trash heap everything gets buried in 30 seconds.
I’m no where near even considering posting it on the “real” Greenlight, that would probably be marketing suicide at this point. :o
Lol pretty epic, had a similar problem yesterday when implementing guns into my game, messed up bullet direction and everything was coming out his rear, nny fitabout 10 seconds
I have completed (for now) the blood particle system, for fun, I put together this special little tech demo download! Play around with it, tell me what you think!
Keep in mind you probably will get framerate drops, because the tech demo allows you to make massive over-the-top blood splatters. But it’s super-fun to goof around with! If you guys think it’s worthy, I may move the tech demo over to featured as a “completed” thing on it’s own.
NOTE: Only tested (and probably only works) on Windows Machines currently!
EDIT: Also, the decay rate is cranked up in the tech demo to run 3 times faster than in the actual game, if you are getting constantly low frame rates when there’s a ton of blood on the ground, you can lower/raise the decay speed with + and -. This should make a substantial boost to your FPS.
Wow, very nice work. works pretty good on my windows laptop, drops down to about 40 fps when i held down the RMB. only real issue was when it was increasing the collision map it slowed down very badly. i like the darker splotches around the map, cool trick.
Thanks. I had a ton of fun making it. Right now it’s the highlight to the engine. hehe.
The slowdown is probably from the BloodTile objects. I need to work on that code, I’m not entirely happy with it.
Basically every time blood hits a new tile on the map a “BloodTile” object is created(if it doesn’t already exist in that spot) and any blood particle that falls on it gets deleted and drawn onto the tile, then each tile runs a few Randoms that control decay rates that pick a random spot on the tile and lower the alpha level. It’s all a tad bit more complicated than that (not really worth going into), but basically the more dispersed your blood is the more of the tiles are running… and since they’re a bit hoggy right now it hurts your frame rate. But, the actual in-game system would never see even close to the amount of blood you’d spew around on the map in the tech demo so I’m not overly concerned. But I do want to fix it, since it’s the bottleneck to the system.
But if you raise the decay rate it should speed up the game substantially, the blood will just take forever to decay. The default in the tech demo is 3x higher than the actual game…
I thought the blood wasnt decaying at all. Putting it on 1 out of 1, I can see it working. The blood looks better once it starts to decay a bit, its color saturation is too high to start with. Try start it with .7 -.8 alpha and see what difference that makes. I just noticed that running the decay on the blood tiles does slow down the game quite a bit, but creating a blood tile seems an issue - when blood is dripping down a wall it lags badly each time a particle reaches an uninitialized tile. are you processing the blood tiles pixel by pixel? or just drawing a transparent texture over them that lowers the whole tiles alpha by 1? im sure the later would be very fast if it can be done.
Yeah, you’re right about the blood saturation, I think I’ll drop it down some. Now that you mention it, it does look way too saturated. I think if I flatten out the reds shades and drop the default alpha a bit it’ll look much better.
Currently the BloodTile basically does a if (random(decayRateYouSet) == 0){do decay stuff}, if it’s successful it picks a random X/Y coordinate, checks if that coordinate it’s alpha level is higher than 0 and if it is, lowers the alpha level of that pixel by 50 and redraws the image.
The big chugger comes from the ImageBuffer when the image is redrawn, the process of redrawing the tile in the buffer and rerendering it is tile is the biggest issue. I’m almost positive I can speed up the process though.
Oddly enough the ImageBuffer is also what draws new particles onto the tile, so that might explain why the dripping blood is also causing you problems. I may have to find an alternative to Slick2d’s ImageBuffer.
-stab in the dark - looks like ImageBuffer stores its data in a byte[] array. Im not sure how FBO’s work or whether slick supports that, but im sure that would be faster to draw to screen.
im not sure why its 37 fps when theres a couple of blood tiles on screen (no active particles) and 44 when i move over so theyre off screen. that means its not just drawing them to screen thats slowing it majorly. what happens when theres blood tiles scattered all over the map?
if you reduced the whole alpha of a blood tile say once a second, then you would also be able to record when the last time it was splattered, and delete the tile when its blood has all disappeared. (this way you dont need to check/set any individual pixels either, except when drawing the active particles)
Well, the problem with that is when you change the alpha level of the image as a whole, it doesn’t actually modify the image itself via the buffer, it just changes the opacity. So when new blood lands on it, the new blood drawn will keep the same alpha level as whatever the tile is currently at, or reset the entire tile back to 255.
Thats where the ImageBuffer idea came from, really the best solution (If I were to keep the ImageBuffer) would be if there was a way to get the ImageBuffer to just change the actual alpha level of the entire image all at once (without a forloop of any kind). But for some reason, it doesn’t look like the ImageBuffer can do that. I’m assuming because all it really is, is a byte[] array so it can’t just change the alpha level across the board, only one pixel at a time.