Problem solved. You dont have problems. Must be something like a plugin like I mentioned before.

Lol, that is funny way to put it.

Ruskul Ha! Definitely been there. This weekend I accidentally discovered that I was creating dialogue boxes EVERY TICK because I had a "create dialogue box at x,y" when two variables were true. They were stacking and looked totally fine in preview. However in the debug I noticed my instance count was ROCKETING up and was all, "Wha? What am I doing wrong?"

That's hilarious, but an insidious bug to be sure. Often when devs play a game, they only play it for a minute or two. Its a good thing you caught that when you did. I could just see me missing it for weeks and then on longer play sessions wondering why performance is tanking. lol

Hey, I have a critique for you based on what I can see of the game. Take it for what it is (my opinion), and do with it as you see fit

Currently, I like the art a fair bit. And by that, I mean I think the art is charming, coherent, and serviceable. Pixel art, as a medium, is always a great choice when making games like these. It is easy to produce, and if experienced, fast to make. However, it does provide certain constraints, and in a lot of cases its best to follow these.

Based on the game tile art, your game apears to have a specific resolution that your art sticks to, but the title screen does not stick to this resolution. It has pixels that are smaller than the pixels in the tilemap. This is a way, makes me as the player ask, why the heck is the title screen in resolution A but the game in resolution B? When you create a pixel art game, part of it looking good comes down to style and skill, but another part of it comes down to consistency. Its like you are creating a world but when you break the rules of your world the player becomes less immersed in that world because it is no longer as believable. Does this make sense? In general, I believe pixel art should never have sub pixels unless it consistently has sub pixels in points of interests everywhere. In other words, if you break a "rule" break it in a way that makes sense in some form or fashion. Don't just break it arbitrarily at one point just because.

The title won't look better just because it is higher resolution. So in its case I would stick to a lower resolution. I would, also not draw it then morph the image, unless done carefully. Currently the title looks like something drawn in ms paint, rather than carefully pixel plotted. Now don't get me wrong, I am not saying it looks bad. It just looks different and is not consistent with the game. Because the title is one of the first things your player will look at, you need it to be a part of your game.

Does this all make sense. I don't mean to sound nit picky or anything, It is just an observation on my part. And it isn't something I would worry about until other higher priority tasks are complete, just something to keep in mind.

Ruskul thanks!

I made good progress on work this week and actually managed to get ahead of schedule.

• Set up mid-game title reveal + changed game title
• Finished up all dialogue and cutscenes
• Installed and set up layout transitions. I recommend these or something like it. Having nice transitions really adds that extra bit of polish.
• Set up pause function and screen
• Got title screen code working and started working on title screen art

What's left, bc?

• This week: Finish title screen and game over screen
• 2nd week: 1/2 of enemy art
• 3rd week: remaining 1/2 of enemy art
• 4th week: music and sfx
• 5th week: bugs and polish

nice, busy busy. Way to keep plowing ahead. I just spent 4 hours last night trying to fix a problem in my game only to find out there was no problem except I was sending the debugger the wrong values from my script... >.>

> What does Firefox have to do with it?

>

My firefox spits and sputters with HTML 5 games. Whenever I am thinking I am having a performance problem, I look up and see that i am testing on Firefox. When i switch to Chrome the performance is the way i would expect it to be....

That is weird, I never have any problems with firefox at all. I normally test chrome because I export to desktop via chrome so , you know..

R0J0hound - That is it in a nutshell. Though I never saved the floating point for x and y because it didn't seem necessary at the time based on how my camera works (its movement comes form being clamped, to flexible boundaries) I like the smoothness of the camera moving in sub pixels, I just don't like it to stop and sit at a sub pixel. So I only round it when the camera is not in motion.

looks cool, keep up the work

bclikesyou - yeah, the general lerp camera is pretty bad at causeing jitters. The bigger your pixels, the more you notice it. I tossed out the lerp camera pretty early on. It takes alot more work but, you can program a camera that accelerates and decelerates to keep an object within an arbitrary bound region. I clamp my values to essentially force certain constraints that minimize slow movement, and other potential jitter producers.

R0J0hound - I actually never use a fixed timestep... including with box2d. Also, when I spoke of resolving a collision using the custom behavior, I meant that I use push out of solid as an action in custom behavior. That behavior is only accurate to within a 10th of a pixel. If the camera is at position x.5 and y.5 then the object in question can appear to jitter.

I have gotten around it by forcing the camera to round to the nearest whole integer when coming to a rest, which skirts the problem nicely. I have been thinking though, I think the renderer could use an upgrade. The fact is, if you move a camera slowly through a scene with a number of objects at arbitrary locations you can really see jitters. An object at x.5 will move before an object at x.0 if you are scrolling sideways. If objects render positions are calculated before being rendered, you can force those shenanigans away. I once made a script that saved an objects position, rounded it to the nearest whole number before rendering, and then at the start of a new frame restored the position (not logically programmed the way I described it, but it essentially provided that). If you round scroll position to the nearest integer, it effectively does the same thing, depending on the circumstances. Its weird too but it also ties into jagged increments in moving on the x and y axis too. The system I made was to make sure a characters position over time didn't draw an ugly line if you know what I mean. Like in pixel art? Does that make sense? I even made a nes like system where I stored only whole numbers in c2's position and then stored the remainder decimals in a custom script. In mario 3 on the nes, for example, everything was calculated in a 4 units per pixel. So an object moving at 1 pixel per frame was said to be moving at 4 units per frame. Of course, unless you can guarantee a specific frame rate, its all only nice theory.

Do you have any visual examples, such as a capx showing the problem? because I'm not sure I understand. I mean, I think I do, but I haven't noticed it before. An example would help get your point across.

I'm also wondering if perhaps there might be camera movement influencing any pixel rounding?

My last post kind of skirted the issue, I just realized. For the most part you need either a camera that is near the drawing pixel boundary ( x.5, or y.5) or an object. If the object is being resolved every frame due to gravity or something pushing it down then you get the problems I was talking about.

Prominent - I'll get an example capx up. As for camera movement, that can surely cause seeming jitters, especially if a camera is moving slowly. In any retro project, I always avoid any camera smoothing as this causes problems. I still have camera movement that may be independent of the player object but its decimal point is tied to the players so that it rounds in favor of the players drawing position if that makes sense. It depends on the games needs of course.

Okay,

Given collision resolution in construct is accurate to 1 pixel (+/- o.05 ish) for a total margin of error of around a 10th of a pixel, it is possible with settings on retro to experience jitters. This of course occurs when an object is pushed out of a collision but a different amount each frame. If the average jitter caused by collision resolution falls within the boundary for rounding objects draw position to one pixel or another then you get actual visible jittering. Does this all make sense?

Given that that the collision resolution error margin is 10% of a pixel you end up getting visable jitters for around 10 percent of any objects life time while being constantly resolved.

Now, in the past, I have gotten around this by implementing my own collision detection and resolution, and the response was always the same. So even if there was a small error due to binary being converted to decimal or the reverse, it was the same every time. This meant no jitters. But when I use constructs collision detection and resolution, I get jitters.

These jitters basically mean you really can't have a polished 2d retro project. You can always not use retro settings, and simulate them by creating 4x sprites with nearest neighbor interpolation, but this is a fair bit of work and means that performance is likely to be lower. In other words, I know of this work around, but would rather not use it. Does anyone else know how to work around this?

I should also point out that box2d's collision detection and resolution resolves to a stasis point and then maintains that point, so you don't get any visible jittering for the most part. I only tend to notice it when I am using construct 2's custom collision resolution tools (custom movement). I would tend to think of this as a bug but figured I would post here first. I can't think of a good reason why given the same distance of intersection each frame why the resolution would vary by a whole 10th of a pixel?