damainman's Recent Forum Activity

  • Escualo We haven't been able to preview or export since 185 or 186 I believe. Similar issue. We just stayed on 184 to do our game updates.

  • Ashley

    Pshhh... I'm totally jerking Jokes aside... with all of the experimenting I've been doing with Insanity's Blade, I'm finding that it might be other issues and not C2/ExporterTypeX.

    I'm saying this because I took a Windows 7-32bit machine with a 460gtx - all drivers up to date - replaced it with a way more under powered card 8600gt and blam - game went from unplayable to occasionally jerky (probably old 5400rpm drive and crap ram).

    Then on my lunch break yesterday, I downloaded our steam build on my work machine. This is probably an early i5 with a 450s. Clean install of windows a couple of months back. I use it for work/unity. I was expecting the game to run bad as It's a pretty bare bones work station. Nope - 60fps - not one little hitch. All drivers up to date. Game ran smoother than on my i7 with 16gb ram and an GTX860m.

    Clean install machines seem to run games in Node Webkit no problem - I bet it I installed a fresh build of windows 7 on my older machine, the game would run without a hitch. The problem is finding what app/drivers are causing the hitching. The old machine does it every half second. But you don't really notice it due to all the action on the screen.

    I'll keep messing around with different machines - and obviously I'm going to get hit with the "your game won't run on my 10+ year old dumpster find, you suck, give me back my money!!!" Mails like when we posted the Demo and early access on Desura. Maybe these findings can at least prove useful to make a FAQ about frame rate issues and drivers

    Oh - We also made a batch file to launch the game with node-webkit commands, this is clearly helping the frame rate:

    --disable-threaded-compositing --ignore-gpu-blacklist --enable-zero-copy --disable-application-cache

    -Chris

  • Zathan This is what is happening with our build on the older machine. I can't remember what's happening with my i7. My specs for working on the game are:

    i7 3.4ghz

    860m 2gb

    16gb ram

    windows 8.1

    i7 3.1ghz

    550m 2gb

    16gb ram

    windows 7 SP1

    and the lowest spec machine that it was previously running smoothly on is:

    core2duo 2.8ghz

    460gtx 2gb ram and 8600gt 256 gbram (I swap them for testing on an actual CRT/arcade machine)

    4gb ram

    windows 7 sp1

  • I've been trying to pin point this jerkiness as well. It started happening for us some point around 174-178. I have more testing to do. I have builds of our game that have no changes between the builds aside of front end and menu items. Testing our last stage with a build from august there was no jittering or jerking in our final stage. But now it's really bad - an d I know that aside of the respawn code, nothing has changed for it at all.

    We were using r184 for our last build (anything higher and the game has completely stopped working in preview mode or even after a full export to anything). I've downgraded to r178 and the jerkiness is still there. Trying with different builds of Node Webkit as well but it makes no difference. I'm going to go back to ~174 this week at some point and test again. We can usually get a pretty even frame rate of 60fps on a mid range machine. I am pretty sure we had the new built in video player plugins in place when I did the last smooth export so I'll post my results when I have time.

    All of my initial testing is done on two i7's with 8/16gb of ram and the game is always 60fps. My low end testing rig is a core2duo 32-bit with 4gb ram and an 8600gt - the game ran smooth with the older build on that.

    DMM

  • v 1.03 of the game will be released Dec 1st on Steam! The game was green lit back in October. Massive updates and bug fixes since initial release on Desura! We will be doing one more massive update which adds more content to the game for the spring. It will contain possibly two new game play events to get coins for the in game store!

  • Yeah, I haven't had freeze bugs yet either. I've completed a few games for clients and aside of this one we have a few other engines half finished and not once have we had a freeze bug that I'm aware of.

    The only thing I've seen was on the lower end machines Node Webkits garbage clean up. When it's about to do it, it stutters and then freezes for a split second. But the last C2 build (r178), that node webkit actually killed the frame rate of the game. At least I hope it was Node Webkit.

  • Shouldn't use than 4gb of ram I think It uses about 500mb tops. Glad it runs well on the i5, thats what one of my rigs is. We're only looking for technical feedback but thanks

    The Mac I ran it on has lower specs, especially the video card but it's a 64-bit machine, over the 32-bit which has more/better everything. So there has to be something to it.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • TunaUppercut I hope you were dying on purpose XD LOL!! Have fun and let me know if anything else has issues! Thanks for testing too!!

  • It seems to be if the cpu is 32-bit or 64-bit. My old core 2 duo is a 32 bit machine. My mac is a core 2 duo 64-bit and I was running the game in boot camp and it was fairly smooth. The specs are low GF9800m GT and I think it's a tad underclocked because it's old and getting over heating issues. The one thing I noticed on the older machines is when it does the garbage clean up it will stutter for a second and sometimes even pause for a few milliseconds and then continue along smoothly.

    My Mac OS is outdated though so I can't run the actual mac version anymore, it starts to load and then craps out.

  • TunaUppercut I fixed it this time, I finally got it to happen to me. For some reason the level reset code isn't happening in order on some machines. I got it to happen on my Macbook Pro (Windows 7 and the core 2 duo is 64bit and the game is actually running smoothly) so I could see exactly what was happening and it was player respawning before the level reset which shouldn't technically happen. So I altered the camera code to fix the issue. I've just tested a bunch and uploaded. Same links as before. But yeah the player spawned into the ground despite the code telling him to spawn -32p above the check point which is players' height on ground.

    I still don't get why it's not happening to everyone. But this new build should fix it, I'll test it on my mac too. I could only get it to happen in the forest as well. I go into the store and then fall into the water right afterwards and he would respawn into the ground.

    ***Update***

    I just killed myself 10 times on the mac and it didn't happen so hopefully it's gone now!

  • TunaUppercut Ok - I can't sleep thinking something is broken when I can do a work around. So I just went in and added -32px to the y pos when respawning. Watching your video shows that the player is getting ahead of the level even starting. It's usually the other way around, you here him make a fall sound before he appears. But the detection there is completely c2 collisions. The floors are solid, so when the level restarts its ignoring the collision detection for the player. Hopefully setting the y pos on respawn to be higher will fix this! Here's a build - I'm going to bed LOL!

    http://causalbitgames.com/demos/nope/win32.zip

  • TunaUppercut Thanks for testing for me. I'll have to write a work around for that in the morning. I may also do a web version of the demo to test in Chrome. At least we can pin point if the problem is C2 or Node Webkit that way.

damainman's avatar

damainman

Member since 6 Jun, 2012

None one is following damainman yet!

Connect with damainman

Trophy Case

  • 12-Year Club
  • Email Verified

Progress

13/44
How to earn trophies