So, I've been working on the final boss for the first act. Let's just say that if you like tentacles, you're going to be happy. And if ya don't, no worries, I believe this is the last appearance for a while.
So now my mind's on tentacles. (Not a terrible place to be, really ;) In the beta, the few tentacles we do see are pretty chill. They just kinda sit there & rock back & forth a bit. That doesn't seem right, in my mind they should be writhing & wiggling all over the place. When I try to do that however, it comes out looking like crap. I see spazing & just jumping around rather than the wiggle movement I want.
Which bring me to the link below, which is illustrating the method I'm trying right now. The actual motion of the tentacle is very similar, but I'm redrawing the outline every other frame. This makes it seem like it's bouncing around a lot. It's pretty close to what I'm trying to achieve. The underlying motion is still rather chill, I may go through one more time & amp that up a bit. But otherwise I'm pretty happy with the improvement.
(I also posted this simply because I didn't know how to embed flash files into a browser. I seem to have figured it out. Hooray for copy/paste. ;)
DirtyC101
Wednesday, August 31, 2011
Thursday, August 18, 2011
Frustrations Per Second
(This is a long post, and mainly code & theory related. Just FYI)
So I mentioned I wanted the game to run faster. There were two more things I wanted to try. The first is optimizing the backgrounds. The default graphic type is vector art, and flipping it to a bitmap is supposed to make the game run faster. It's a pretty simple change, you just add this code to the 1st frame of the clip:
this.cacheAsBitmap = true
I don't quite understand why this works BTW. It has something to do with vector art requiring more resources when it needs to update (Vector art can also do more, like spin or zoom easily, so vector art is also the safer choice most times). What I do understand is that the first time I tried it the results were just crazy good, possibly better than the quality button. Unfortunately, subsequent applications were not so incredible, and often I couldn't see any improvement at all.
So I decided to try & be a bit more scientific about this. I built a shitty little FPS counter by placing this code in the main loop:
newtime = getTimer()
_root.xxx = _Math.round(1000 / (newtime - oldtime))
oldtime = newtime
There's some variable declarations elsewhere of course, and _root.xxx is just the name of a global variable I use when I'm chasing errors. With this 'tool', I then altered the background in small steps. I also reset horde mode to spawn exactly 10 monsters just off from the hero. And here's what I found: (I should note that the FPS output was an integer, so the decimal point is my interpretation of how often it was flipping around.)
FPS
Original Background: 3.4
Bitmap, built from movie clips: 3.9
Bitmap, drawn from shapes: 4.0
No Background: 5.1
Yeah, that's some shitty FPS there eh? It's supposed to be 20. But it does show an improvement with this bitmap idea, so at least it's a step in the right direction.
The other thing I wanted to play with was optimizing the symbols that make up the bad guys. I think I've mentioned this before, but there's a simplify tool that will substantially reduce the line count of your symbols (The command is in the main toolbar, under Modify, Shape, Optimize). I played with this in the past & wasn't impressed, so this time around I cranked it to max settings. Not as a permanent change, more to see if it would do anything at all. In my mind, this should be very similar to what the quality toggle is doing, so I was hoping to perhaps find a good middle ground between graphics & performance. And here's what I got:
Normal Monsters Optimized Monsters
Original Background: 3.4 4.0
Bitmap, built from movie clips: 3.9 4.2
Bitmap, drawn from shapes: 4.0 3.7
No Background: 5.1 4.6
Now call me a pessimist, but the FPS numbers between the normal & optimized are virtually the same in my opinion. There's no clear indicator that optimizing the shapes improved performance at all. (This also tells me there's a lot of error in my data gathering ability, but that's nothing new. hahah). In my mind, it does show a small improvement with the bitmap idea though, so I'm going to keep doing that for backgrounds. And it looks like it doesn't matter how the backgrounds are built either, which is nice because it means I don't have to change a lot. hehe.
So, that's my conclusions from this. What do y'all think? If I toggle the quality button to low, the FPS jumps up to anywhere from 12 to 20. So clearly the quality button is doing more than the optimize shape command. In my opinion, that also means the bulk of the processing time is being spent on the graphics, not the code. I reckon that's a good thing, but I'm not sure there's much I can do to fix it, short of 'draw less'.
DirtyC101
So I mentioned I wanted the game to run faster. There were two more things I wanted to try. The first is optimizing the backgrounds. The default graphic type is vector art, and flipping it to a bitmap is supposed to make the game run faster. It's a pretty simple change, you just add this code to the 1st frame of the clip:
this.cacheAsBitmap = true
I don't quite understand why this works BTW. It has something to do with vector art requiring more resources when it needs to update (Vector art can also do more, like spin or zoom easily, so vector art is also the safer choice most times). What I do understand is that the first time I tried it the results were just crazy good, possibly better than the quality button. Unfortunately, subsequent applications were not so incredible, and often I couldn't see any improvement at all.
So I decided to try & be a bit more scientific about this. I built a shitty little FPS counter by placing this code in the main loop:
newtime = getTimer()
_root.xxx = _Math.round(1000 / (newtime - oldtime))
oldtime = newtime
There's some variable declarations elsewhere of course, and _root.xxx is just the name of a global variable I use when I'm chasing errors. With this 'tool', I then altered the background in small steps. I also reset horde mode to spawn exactly 10 monsters just off from the hero. And here's what I found: (I should note that the FPS output was an integer, so the decimal point is my interpretation of how often it was flipping around.)
FPS
Original Background: 3.4
Bitmap, built from movie clips: 3.9
Bitmap, drawn from shapes: 4.0
No Background: 5.1
Yeah, that's some shitty FPS there eh? It's supposed to be 20. But it does show an improvement with this bitmap idea, so at least it's a step in the right direction.
The other thing I wanted to play with was optimizing the symbols that make up the bad guys. I think I've mentioned this before, but there's a simplify tool that will substantially reduce the line count of your symbols (The command is in the main toolbar, under Modify, Shape, Optimize). I played with this in the past & wasn't impressed, so this time around I cranked it to max settings. Not as a permanent change, more to see if it would do anything at all. In my mind, this should be very similar to what the quality toggle is doing, so I was hoping to perhaps find a good middle ground between graphics & performance. And here's what I got:
Normal Monsters Optimized Monsters
Original Background: 3.4 4.0
Bitmap, built from movie clips: 3.9 4.2
Bitmap, drawn from shapes: 4.0 3.7
No Background: 5.1 4.6
Now call me a pessimist, but the FPS numbers between the normal & optimized are virtually the same in my opinion. There's no clear indicator that optimizing the shapes improved performance at all. (This also tells me there's a lot of error in my data gathering ability, but that's nothing new. hahah). In my mind, it does show a small improvement with the bitmap idea though, so I'm going to keep doing that for backgrounds. And it looks like it doesn't matter how the backgrounds are built either, which is nice because it means I don't have to change a lot. hehe.
So, that's my conclusions from this. What do y'all think? If I toggle the quality button to low, the FPS jumps up to anywhere from 12 to 20. So clearly the quality button is doing more than the optimize shape command. In my opinion, that also means the bulk of the processing time is being spent on the graphics, not the code. I reckon that's a good thing, but I'm not sure there's much I can do to fix it, short of 'draw less'.
DirtyC101
Tuesday, August 16, 2011
K is for Kwality
So, some of you may have noticed that the game gets slow when there's too many enemies on the screen. Ever since day 1, I've been convinced that the problem lies in the code. In particular, I rely heavily on the hitTest() command, which known to be processor intensive. In order to minimize this, I nest the hitTests under layers of if() statements. The theory is that an if() statement is quick, while a hitTest() is not. And if I can get an if() statement to flag false, then I can skip the hitTest() entirely. Okay, maybe I'm not explaining it very well, but when it was explained to me it sounded solid enough. haha.
So, did all that. Actually been doing it since my first game, and I do think it helps. But it's not enough. While I was away, Renara (LoK forums) posted a bit about optimizing code. And that really got me looking at my code again. Although I knew it was bad form, I often had 2 or 3 onClipEvent() loops running simultaneously, as it was just easier for me to code. So I went back & fixed that. And once again, it helped, but it's not the miracle fix I was hoping for.
What it did fix however is that now when I'm fighting several enemies, if I scroll the screen to hide most of them, the game suddenly speeds back up again. This made me start thinking that maybe this isn't entirely a code problem after all. Some of y'all had requested a 'quality' button, which was pretty common in older Flash games. I really hadn't even considered it, but after digging some I found the commands & figured I'd give it a whirl. And sure enough, with the video quality set to low, the game now runs great. And WOW does it look like utter shit. Enjoy the picture below, it reminds me of like an old 8 bit game gone horribly wrong.
So for those of you who prefer speed, there's going to be a quality button. I'm not real happy with that fix though, so I'm going to play with the sprites that make up the monsters, and see if further optimizing their shapes can speed the game up some more.
DirtyC101
So, did all that. Actually been doing it since my first game, and I do think it helps. But it's not enough. While I was away, Renara (LoK forums) posted a bit about optimizing code. And that really got me looking at my code again. Although I knew it was bad form, I often had 2 or 3 onClipEvent() loops running simultaneously, as it was just easier for me to code. So I went back & fixed that. And once again, it helped, but it's not the miracle fix I was hoping for.
What it did fix however is that now when I'm fighting several enemies, if I scroll the screen to hide most of them, the game suddenly speeds back up again. This made me start thinking that maybe this isn't entirely a code problem after all. Some of y'all had requested a 'quality' button, which was pretty common in older Flash games. I really hadn't even considered it, but after digging some I found the commands & figured I'd give it a whirl. And sure enough, with the video quality set to low, the game now runs great. And WOW does it look like utter shit. Enjoy the picture below, it reminds me of like an old 8 bit game gone horribly wrong.
So for those of you who prefer speed, there's going to be a quality button. I'm not real happy with that fix though, so I'm going to play with the sprites that make up the monsters, and see if further optimizing their shapes can speed the game up some more.
DirtyC101
Saturday, August 6, 2011
August Update
I'm sure everyone's wondering when the next update will be. I don't know. I'll probably put out another beta before the final release, but until I feel I've got something worth showing or testing, I'm going to keep the actual game under wraps. On the up side, I'm hoping to have the full game done before the end of the year (3 games in 2010 & nothing in 2011 would be pretty lame, imo).
Let's talk about noise. What do you call all the moaning, panting, & screaming that the chic does during sex? For the sake of keeping this short, let's just say 'voice' It's pretty much the only noise the characters have during the game, so I think calling it their voice fits. That's what I've been working on the last few days. I've never been happy with how I've done this in the past. The girl's voice has always been called by the animation timeline. So say whenever there was a thrust animation, the first frame would also play a moan sound. The problem with this is that some of the animation loops are less than half a second. In order to keep the sound from clipping itself, I had to cut the voice samples to be shorter than half a second. Which just sounds like shit, imo.
I had a new plan to fix all this. I was going to make longer sound clips, and loop them based on the sex position. The problem is now that I have it working, I don't like it. The sounds don't sync with the motions, and because the voice loops are still fairly short it gets repetitive very quickly. It may be even worse than the old method, as at least with the old method I could squeeze in some variety with some random calls.
So, I've decided to scrap this new system. Unfortunately, I haven't figured out what I want to try next. Voices are very important (imo), and I want to get this nailed down before I make too much more of the game. I'm sure I'll puzzle out something, but progress is slow when I don't have a target to aim at. On the up side, I've now got a much better handle on how the onSoundComplete command works (It triggers code when the sound stops, but you HAVE to call a function with it. That was a bit beyond me when I first started).
That's most of what I've been doing lately, so no new picture this month. Oh, I did add a run button though. Technically it works just fine. However now when you're running you can't go through doors. Yes, I'll get that fixed, but I thought it was funny. Crazy code, always doing exactly what I tell it to do. =D
DirtyC101
Let's talk about noise. What do you call all the moaning, panting, & screaming that the chic does during sex? For the sake of keeping this short, let's just say 'voice' It's pretty much the only noise the characters have during the game, so I think calling it their voice fits. That's what I've been working on the last few days. I've never been happy with how I've done this in the past. The girl's voice has always been called by the animation timeline. So say whenever there was a thrust animation, the first frame would also play a moan sound. The problem with this is that some of the animation loops are less than half a second. In order to keep the sound from clipping itself, I had to cut the voice samples to be shorter than half a second. Which just sounds like shit, imo.
I had a new plan to fix all this. I was going to make longer sound clips, and loop them based on the sex position. The problem is now that I have it working, I don't like it. The sounds don't sync with the motions, and because the voice loops are still fairly short it gets repetitive very quickly. It may be even worse than the old method, as at least with the old method I could squeeze in some variety with some random calls.
So, I've decided to scrap this new system. Unfortunately, I haven't figured out what I want to try next. Voices are very important (imo), and I want to get this nailed down before I make too much more of the game. I'm sure I'll puzzle out something, but progress is slow when I don't have a target to aim at. On the up side, I've now got a much better handle on how the onSoundComplete command works (It triggers code when the sound stops, but you HAVE to call a function with it. That was a bit beyond me when I first started).
That's most of what I've been doing lately, so no new picture this month. Oh, I did add a run button though. Technically it works just fine. However now when you're running you can't go through doors. Yes, I'll get that fixed, but I thought it was funny. Crazy code, always doing exactly what I tell it to do. =D
DirtyC101
Wednesday, July 20, 2011
play();
My plan was to start slowly, and mainly just work on the drawing stuff to get my feet wet again. Yeah, that plan lasted about 5 minutes.
One of the problems I mentioned back when the game was posted is that opening the inventory while a grab is ending will lock the game up. (This is a different bug than the lockup during a scene change BTW, but I think I have that one fixed too). This particular bug is caused by having two simultaneous gotoAndPlay() calls that point to the same frame. So, Play + Play = Stop. I guess that's like hitting the play button twice on your VCR (lol, I'm old), the game pauses instead of playing.
This is one of those bugs that I have really wanted to fix, and every time I came back to it, nothing. Hours wasted here, lots of checks & BS added, and still nothing. I just had one of those "fuck, THAT makes it work?" moments, and it's so dumb that I feel it needs to be shared. heh. Turns out putting a play() command on the target frame keep the game moving. It's a dumb solution (Play + Play + Play = Play?), but at this point I'm really happy with a dumb solution. =D
Why is all this even remotely important you might ask? Because only some of the weapons grant invulnerability with their S attack. If you're surrounded & trying to make some room as a grapple is ending, sometimes it's better to switch weapons first. And now that's finally an option.
DirtyC101
One of the problems I mentioned back when the game was posted is that opening the inventory while a grab is ending will lock the game up. (This is a different bug than the lockup during a scene change BTW, but I think I have that one fixed too). This particular bug is caused by having two simultaneous gotoAndPlay() calls that point to the same frame. So, Play + Play = Stop. I guess that's like hitting the play button twice on your VCR (lol, I'm old), the game pauses instead of playing.
This is one of those bugs that I have really wanted to fix, and every time I came back to it, nothing. Hours wasted here, lots of checks & BS added, and still nothing. I just had one of those "fuck, THAT makes it work?" moments, and it's so dumb that I feel it needs to be shared. heh. Turns out putting a play() command on the target frame keep the game moving. It's a dumb solution (Play + Play + Play = Play?), but at this point I'm really happy with a dumb solution. =D
Why is all this even remotely important you might ask? Because only some of the weapons grant invulnerability with their S attack. If you're surrounded & trying to make some room as a grapple is ending, sometimes it's better to switch weapons first. And now that's finally an option.
DirtyC101
Wednesday, July 6, 2011
July Update
July? WTF happened to June???
Short answer: Computer problems.
Longer answer: I have 2 PC's. I keep one in the living room for playing modern games. When that gets too old & gets replaced, I don't throw it away. I bring it to my room & use it to surf porn & write my games. If y'all remember from a few months ago, the game was reaching a size where my slower machine really was struggling. And my good machine was kinda old too, but it's not quite ready for its second life. So I decided to only buy some key parts for the fast machine, and then the parts that were replaced would trickle down to the porn machine.
And that's when the shit hit the fan.
So, for the last few months I've really been out of touch in the porn circles. The good machine has been working great, and I've been happily addicted to some new (non-porn) games. The porn machine though has been giving me fits. I seriously think I've re-re-re-re-re-re-re-re-installed Windows XP about a dozen times over the last 2 months. Everything from hard drive failures to burnt processors to bad RAM, and lately a series of random bluescreens which I *THINK* might be a driver issue, but still haven't 100% nailed down.
Anyway, point of this note is simply that I'm not dead. And as much fun as Sims Medieval is, there's not nearly enough naked for a game with 'slutty' as a character option. So I've already started working on the porn machine in earnest again (I'm using it for this note), and I suspect you'll start seeing real posts from me again in another month or two.
Til next time
DirtyC101
Short answer: Computer problems.
Longer answer: I have 2 PC's. I keep one in the living room for playing modern games. When that gets too old & gets replaced, I don't throw it away. I bring it to my room & use it to surf porn & write my games. If y'all remember from a few months ago, the game was reaching a size where my slower machine really was struggling. And my good machine was kinda old too, but it's not quite ready for its second life. So I decided to only buy some key parts for the fast machine, and then the parts that were replaced would trickle down to the porn machine.
And that's when the shit hit the fan.
So, for the last few months I've really been out of touch in the porn circles. The good machine has been working great, and I've been happily addicted to some new (non-porn) games. The porn machine though has been giving me fits. I seriously think I've re-re-re-re-re-re-re-re-installed Windows XP about a dozen times over the last 2 months. Everything from hard drive failures to burnt processors to bad RAM, and lately a series of random bluescreens which I *THINK* might be a driver issue, but still haven't 100% nailed down.
Anyway, point of this note is simply that I'm not dead. And as much fun as Sims Medieval is, there's not nearly enough naked for a game with 'slutty' as a character option. So I've already started working on the porn machine in earnest again (I'm using it for this note), and I suspect you'll start seeing real posts from me again in another month or two.
Til next time
DirtyC101
Sunday, May 8, 2011
May Update
Feel kinda silly calling this an update, because I haven't touched the game since my last post. But, my list of 'busy' is getting shorter by the day. With luck, I'll be back in the saddle again by the middle of this month. On the upside, one of the fun results from all this work is I should have a new(er) computer to work with, so it's definitely not a total wash. haha
There were 2 big bugs y'all found, and wanted to talk about them a bit. (Yay for sorta - code theory!) The first is that the game will lock if you mash buttons during a scene change. That has to do with how commands are sent & executed. If you can imagine, once you press the A button to attack, I have to tell the program to stop accepting further inputs of the A button, or it will keep sending you the the first frame of the attack animation until you let go of the A button. Conversely, the final frame of the attack routine tells the program that the attack has ended, which resets the hero back to the default state. The problem here is that a scene change interrupts the attack routine. The last frame never plays, which means it can never reset the hero. So, the program thinks you're still in the middle of an attack & won't accept new inputs, but it will never get that reset signal because the animation was stopped. This one should actually be a pretty easy fix. Simply tell the end of the scene loader to reset any attacks. Or I could lock the keyboard from inputs during scene changes.
The second is that if you die & continue while double teamed, one of the monsters will become invisible/invulnerable. There were no double team animations until about two weeks before the release. This was the last feature I added, and no real surprise, I missed something. In this case, I simply forgot to tell the continue code to check for a second monster in a grapple. So when you continue, it never properly loads the second monster back. He's still there, but his sprite is 'lost'. Actually, it's off-screen, which is where I 'hide' sprites I know I need but don't want to show at that time. What I find interesting is that some of the hit attacks from this off-screen monster still seem to work normally. In my mind, they shouldn't. (And that is neat, imo.) Anyway, this should be a simple fix of telling the continue button to check for a 2nd grappler & reload them if necessary. Hell, I may not have to even run the check, I may simply tell it to reload two grapplers every time, and if the 2nd grappler isn't there it shouldn't do anything.
And since I like to end with at least one picture, here's one from the ULMF forums that made me lol. One of the guys there hacked the game's variables so that they can be set to anything - note the 859 continues. ;)
Til next time
-DirtyC101
There were 2 big bugs y'all found, and wanted to talk about them a bit. (Yay for sorta - code theory!) The first is that the game will lock if you mash buttons during a scene change. That has to do with how commands are sent & executed. If you can imagine, once you press the A button to attack, I have to tell the program to stop accepting further inputs of the A button, or it will keep sending you the the first frame of the attack animation until you let go of the A button. Conversely, the final frame of the attack routine tells the program that the attack has ended, which resets the hero back to the default state. The problem here is that a scene change interrupts the attack routine. The last frame never plays, which means it can never reset the hero. So, the program thinks you're still in the middle of an attack & won't accept new inputs, but it will never get that reset signal because the animation was stopped. This one should actually be a pretty easy fix. Simply tell the end of the scene loader to reset any attacks. Or I could lock the keyboard from inputs during scene changes.
The second is that if you die & continue while double teamed, one of the monsters will become invisible/invulnerable. There were no double team animations until about two weeks before the release. This was the last feature I added, and no real surprise, I missed something. In this case, I simply forgot to tell the continue code to check for a second monster in a grapple. So when you continue, it never properly loads the second monster back. He's still there, but his sprite is 'lost'. Actually, it's off-screen, which is where I 'hide' sprites I know I need but don't want to show at that time. What I find interesting is that some of the hit attacks from this off-screen monster still seem to work normally. In my mind, they shouldn't. (And that is neat, imo.) Anyway, this should be a simple fix of telling the continue button to check for a 2nd grappler & reload them if necessary. Hell, I may not have to even run the check, I may simply tell it to reload two grapplers every time, and if the 2nd grappler isn't there it shouldn't do anything.
And since I like to end with at least one picture, here's one from the ULMF forums that made me lol. One of the guys there hacked the game's variables so that they can be set to anything - note the 859 continues. ;)
Til next time
-DirtyC101
Subscribe to:
Posts (Atom)