Rayvolution
|
 |
«
Reply #30 - Posted
2014-03-03 06:56:54 » |
|
Screen-cast-o-matic is free and does Gif recording straight from the desktop.
Also, haven't commented yet, but this looks great!
Hah, pretty nifty little java program there. Its Gif quality is a bit jumpy, I think it's rigged to skip every other frame, but it got the job done! The rain is much more fluid in the game, but you get the idea.  Thanks for the complements btw  <IMAGE REMOVED, SEE NEW POST BELOW FOR UPDATED VERSION!>
|
|
|
|
kpars
|
 |
«
Reply #31 - Posted
2014-03-03 07:04:05 » |
|
This game is beautiful, and I feel like it deserves a lot more attention! Just wanted to get that out there.  - Jev
|
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Rayvolution
|
 |
«
Reply #33 - Posted
2014-03-03 07:15:21 » |
|
I might give that one a shot later, the examples in the link look promising.  ..that or just get off my butt, install FRAPs and do a proper YouTube video. 
|
|
|
|
kpars
|
 |
«
Reply #34 - Posted
2014-03-03 07:17:06 » |
|
You do realise you can record videos to a file output with OBS (Open Broadcaster Software), right?
Just go into the Settings : Broadcast Settings. Then change the mode to File Output Only. Works like a charm.
- Jev
|
|
|
|
Rayvolution
|
 |
«
Reply #35 - Posted
2014-03-03 07:26:38 » |
|
You do realise you can record videos to a file output with OBS (Open Broadcaster Software), right?
Just go into the Settings : Broadcast Settings. Then change the mode to File Output Only. Works like a charm.
- Jev
Oh yeah, I know. But the output quality is god-awful for pixel art, since the compression OBS uses by default seems to obliterates the nice crisp lines.  But, I'll be honest, I didn't play with it all that much since my intention was to just install FRAPs eventually. The gif I posted a hour~ ago looks much better than anything I was outputting with OBS. 
|
|
|
|
HeroesGraveDev
|
 |
«
Reply #36 - Posted
2014-03-03 07:29:16 » |
|
If you're on Windows you can get Microsoft Expression Encoder which is high quality and no lag screen recording. Also free.
|
|
|
|
Rayvolution
|
 |
«
Reply #37 - Posted
2014-03-03 16:19:59 » |
|
Finally got fraps back up and running, so I made a proper GIF! Enjoy  Obviously in-game the rain doesn't "loop" like that, the rain is a bunch of programmed images, when they hit the bottom they go back up to the top of the screen at a random X coordinate, so there's absolutely no way to make a smooth looping gif since the rain is truely random. But hey! You get the idea. http://sixtygig.com/junk/mainMenuGif3.gif <--full size link
|
|
|
|
|
Drenius
|
 |
«
Reply #39 - Posted
2014-03-04 17:29:38 » |
|
Again, very nice artstyle, looks very good! But as mentioned before, do really try to equalize the perspective, it destroys the whole look a bit.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
|
RobinB
|
 |
«
Reply #41 - Posted
2014-03-10 14:58:46 » |
|
Whow, isnt it a bit early for now?
|
|
|
|
Rayvolution
|
 |
«
Reply #42 - Posted
2014-03-10 17:46:10 » |
|
Whow, isnt it a bit early for now?
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. 
|
|
|
|
Rayvolution
|
 |
«
Reply #43 - Posted
2014-03-12 01:29:49 » |
|
Silly things that happen by accident when you're coding new stuff. 
|
|
|
|
LiquidNitrogen
|
 |
«
Reply #44 - Posted
2014-03-12 01:36:59 » |
|
Your game is perfect now!
|
|
|
|
Opiop
|
 |
«
Reply #45 - Posted
2014-03-12 01:37:51 » |
|
Yupp, export it and release it everywhere! "Butt Bleeder The Game". Who wouldn't play it?
|
|
|
|
BurntPizza
|
 |
«
Reply #46 - Posted
2014-03-12 01:50:46 » |
|
Surgeon Simulator 2014! Bask in the glory hemorrhaging all over the place!
|
|
|
|
Rayvolution
|
 |
«
Reply #47 - Posted
2014-03-12 02:53:48 » |
|
Yupp, export it and release it everywhere! "Butt Bleeder The Game". Who wouldn't play it?
With "color changing blood" DLC!
|
|
|
|
|
Gibbo3771
|
 |
«
Reply #49 - Posted
2014-03-12 06:01:03 » |
|
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
|
"This code works flawlessly first time and exactly how I wanted it" Said no programmer ever
|
|
|
wessles
|
 |
«
Reply #50 - Posted
2014-03-13 02:12:39 » |
|
Must... resist... posting... to... /r/gamedev... !
|
|
|
|
Rayvolution
|
 |
«
Reply #51 - Posted
2014-03-20 02:53:45 » |
|
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. CLICK HERE TO PLAY WITH THE BLOOD PARTICLE TECH DEMO!(Download, unRAR and run BloodTechDemo.jar) 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.
|
|
|
|
LiquidNitrogen
|
 |
«
Reply #52 - Posted
2014-03-20 04:19:55 » |
|
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.
|
|
|
|
Rayvolution
|
 |
«
Reply #53 - Posted
2014-03-20 04:52:44 » |
|
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.. 
|
|
|
|
LiquidNitrogen
|
 |
«
Reply #54 - Posted
2014-03-20 05:21:34 » |
|
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.
|
|
|
|
Rayvolution
|
 |
«
Reply #55 - Posted
2014-03-20 05:35:21 » |
|
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.
|
|
|
|
LiquidNitrogen
|
 |
«
Reply #56 - Posted
2014-03-20 06:07:46 » |
|
-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.
|
|
|
|
Rayvolution
|
 |
«
Reply #57 - Posted
2014-03-20 06:09:55 » |
|
-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.
Yup. You're absolutely right, it uses a byte[] array.  I was just looking into Slick's FBO functions. I've never used them before, but they look promising. 
|
|
|
|
LiquidNitrogen
|
 |
«
Reply #58 - Posted
2014-03-20 06:19:52 » |
|
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)
|
|
|
|
Rayvolution
|
 |
«
Reply #59 - Posted
2014-03-20 06:54:43 » |
|
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. :/
|
|
|
|
|