Messages

With a lot of game jams you are actually allowed to work on the story any time you like and the competition time is for programming the game and art so I'm personally okay with someone using a pre existing story as it's kind of like someone using a story they wrote a year ago.

I would say though, technically it's not a game jam and is 'MAGS', so I'm happy with whatever the outcome of a vote or just simply a yes/no from Myinah/Sox.

At the end of the day if I get another game to play this month I won't complain

But the main reason I was adding this is to let a workaround for non-standard mouses. What could be the solution here?

Well I'm really at a loss as it's just an extremely strange mouse movement - I have never experienced it in any game I have ever played. Unfortunately I'm also not a good enough programmer to tell you if it's simply the engine you are working with or something in your own code, however, something does tell me it's an underlying problem.

You have improved it, there is no doubt about that, but there is still acceleration present when you move the mouse more suddenly. If that is something that is hard coded into Allegro then perhaps the best idea is to wait and see if we go down the Allegro 5 route, and hope that we can sort the issue that way.

The only way I know how to explain it is to reference what an FPS player would call a 'twitch' movement. Moving the mouse around the screen at a constant smooth speed it functions 100% normally, however, if I were to move very quickly say 30 pixels from left to right, my mouse is not where I expect it to be (or where it would be if I did the same movement in windowed mode), it ends up 120 pixels to the right due to acceleration kicking in.

I don't understand, what "bounds" you mean, can you elaborate please?

I was merely comparing to the last version I tested in which the mouse in fullscreen could leave the screen edges. I think you fixed it a while back so now the mouse is always on screen no matter how much you drag it left, right etc. That was just a fullscreen issue and like I say I think it was a slight error in the code and you swiftly sorted it.

Would you like me to do a screen capture of a test game so you can see the issue in real-time?

Hi CW, really sorry it's taken me this long to test it!

The changes and new commands are all functioning perfectly, however, it does still seem to retain some acceleration I'm afraid.

It's almost perfect on a standard mouse but with the high DPI mouse the user must be very careful when moving around. If you move the mouse suddenly then the acceleration kicks in and takes it way off course.

Everything is now staying in bounds though so it's certainly much more useable than the current stable build.

5th of March sounds perfect, thanks

I like the art style st. and look forward to giving it a go!

I would also like to ask for a bit of an extension if that's okay. 2 days would be fine, or a little longer if it suits others?

I'll second what selmiak has said, the graphics are stunning and it only gets better after listening to some of that music. Great stuff.

Hi all,

Some good looking entries already!

I thought I'd give everyone a head's up I am also joining in this month. I'm going to continue with a low-res style like I tried last month but try to work on a new universal interface as my last game provided some useful feedback on how it could be improved.

This is an in-game screenshot but I'm keeping the interface a secret for now (as it's half done ).

[imgzoom]http://calicoreverie.co.uk/wp-content/uploads/IAMJASON1.png[/imgzoom]

Hi CW,

Thanks for putting together that test build. I've had a little play around but will get you some proper tests on different setups done hopefully in the next couple of days.

Unfortunately the only test I've managed to do (using my gaming mouse with stupidly high DPI and custom drivers e.g. the stuff that seems to mimic the Logitech Setpoint issues) hasn't worked 100%. The actual changes do have an effect and I can now control the sensitivity but there is still a point at which acceleration is applied and I lose control of the mouse.

Good part of the test:

• the ability to control the mouse by moving it carefully is MASSIVELY improved, literally to the point where it would be playable
• works great in windowed mode!

Bad part of the test:

• the mouse can go "out of bounds" and you have to carefully bring it back to gain control of the pointer image again
• it's possible to almost completely "lose" the mouse as there just seems to be no bounds anymore

On a side note, I might be being stupid but are the setup commands spelled incorrectly?
sensivity = 1.0 // overall sensivity (floating point value)
sensitivity = 1.0 // overall sensitivity (floating point value)

Congrats Dropped Monocle, very worthy winners indeed.

I am currently interested in testing out another solution I found, using get_mouse_mickeys function.

Well, I must point out that this will work in fullscreen mode only.
Allegro does not let me control mouse position outside of the window, therefore I can't know actual cursor coordinates on screen, can't even know when mouse left the game window. Since I keep adjusting cursor position, mouse can't leave the window at all.
For sensivity to work in windowed mode I would need to descend to OS API mouse functions.

I second that that would be absolutely fine. Id hesitate to say that's exactly how it should work anyway.

I really like the style, it works very well with the background.

2 quick pointers would be:

The head only seems to bob one pixel down on the 3rd frame I think, in a walk cycle, your head would go from say level, to lower, back to level, then higher, then back to level if that makes sense, like a bobbing motion. Yours stays level for all frames apart from 1. I'd say the 1st frame needs to raise his head to create that bobbing motion.

His arms could do with being a little bit longer in the down/up view. If you look at the diagonal or left/right views, his hands are well below his jumper/top and over his trousers. I think this needs to be reflected more on the up/down views. Unfortunately this also means tweaking some of the frames on the animation in my honest opinion.

If anything doesn't make sense just let me me know as I can get you some references later when I'm not at work.

When you say first loop, do you mean you are still to do more frames for the down animation? 5 frames for a walk cycle is rather odd. I would have thought it would be an even number? I think his right leg 'jumps' a bit when it goes forward as you need 1 more frame.

Quick update, I found a forum post from a user stating that allegro 4 has issues with fullscreen mouse acceleration and that allegro 5.0.5 'fixed' the issue. I say 'fixed' as he states: "i had to port my infinite perlin noise terrain generator to allegro 5.0.5 to get the mouse to work in fullscreen without annoying excessive acceleration." - so it might just be useable rather than removed.

So far I've just been chucking in global variables called something like storySection1Panel - I'll set this to a number (just in case of multiple states) and then change it when the player opens the panel for example. In the room load function I then just check for all the various story global variables I have for that room and update the required objects, hotspots, walkable areas etc

I've had a look in the modules and I found a something by Calin Leafshade called Story State. It's download link is broken but he does go on to say that it's only good for 50 levels or states. That worries me a lot for a full-length game, it seems rather few considering that in a small proof of concept I have already used about 5 story states in a single room. Although I do love the idea of setting the 5th story state to true and it will auto set 4, 3, 2, 1 to true as well, that would save a lot of time when testing.

Am I missing something silly that's more built into AGS than I know about or does everyone else follow the same route of just adding in global variables?

Great looking game, the level originality is amazing

I could stare at the rain coming down those windows for hours on end and can only imagine how good it'll be in game with sound!

Yea it could be stupidly slow because the engine was set up by default to have a medium amount of acceleration. If that was always on by default then in theory I understand  why the mouse speed would be hardwired so low.

Thanks for having a look anyway, hopefully the stupidly slow mouse speed was due to eliminating acceleration and now it's just a case of upping the speed in another way.

Hi, sorry Dualnames, I was searching for mouse acceleration so missed your post.

I've tried the code you posted but didn't have much luck I'm afraid (the code that monkey_05_06 modified unfortunately didn't help either, if anything it was worse).

Crimson Wizard, the screen metrics being input parameters seems interesting as my tests do indicate that the problem is less evident the higher the resolution of the game but I have even tested a full 1920x1080 game running and the mouse acceleration makes the game (for me anyway) unplayable. If I needed to do any sort of precision movement within say 100 pixels then it's OK but if I need to just move around the screen it accelerates beyond control.

When you talk about the value 0 for mouse_accel_fact being too slow, what do you mean exactly? Does it feel like acceleration is off, but the mouse speed is stupidly slow? I'm afraid my knowledge of allegro and windows programming in general is very limited.

Does it not differ between accelerating the mouse and the speed of the mouse? E.g. I would expect as a user that if the acceleration was turned off and my mouse speed was very low, I'd just hop into the settings and increase the mouse speed to suit.

I've been doing a few tests on various devices as I've recently made a super low res game (160x90 in the new alpha 3.4.0.3) and have had issues with the mouse movement in fullscreen. No matter what settings I play with and what hardware I use, there still seems to be something off with the mouse movement (I'm not sure if anything was ever even addressed as the other topics just seemed to fizzle out months/years ago).

All tests have been windows 7 based using the following equipment:

• a laptop (running at 1366x768) using the track pad
• a laptop (running at 1366x768) using a default cheap mouse with no drivers
• a desktop PC (running at 1080p) using a high end razer gaming mouse (razer synapse drivers - similar to logitech and set point I imagine)
• a desktop PC (running at 720p) using a default cheap mouse with no drivers

I've used pretty much all of the combinations of settings to scale the game when in fullscreen and all act the same.

The best fullscreen mouse movement seems to be split between the laptop using the track pad and the desktop PC 720p with default mouse no drivers. The worse movement is on my desktop PC with the razer mouse tweaked for optimal FPS settings (high DPI, polling rate etc).

However, in every single case, no matter what tech or drivers, there is definitely mouse acceleration present (I play a lot of FPS games so I know when my mouse doesn't feel right). It ranges from barely noticeable to horribly evident and unusable. My problem is that whatever settings I set my razer mouse/windows settings to (0 acceleration everywhere possible) it is still present when running fullscreen in the AGS engine.

I can live with no settings to change sensitivity in game as it's trivial to set my mouse speed to whatever works with the game (sensitivity options for the user would be perfect, but not needed).

But why does AGS apply acceleration seemingly hard wired in?

I used a very simple effect in my MAGS game which may translate to what people are saying about 'hard' shadows (I used far, far fewer colours by default though).

Basically, I complete the scene then I add layers of very transparent black, white, yellow etc and just paint over with a solid pixel brush till it feels right. - here is a very rough example which basically just re-does your soft shadows into a non aliased pixel brush:

[imgzoom]http://calicoreverie.co.uk/wp-content/uploads/2015/02/shaun9991.png[/imgzoom]

What I've found by doing this is it is much easier to 'try' something and it's just faster producing graphics in general (I added 4 layers and painted those shadows on in about 2 minutes). It does obviously go without saying that the style that chicky did is more 'correct' to pixel art.

The look and style is awesome.

I have looked into a ton of engines and have used things like Unity and Stencyl but haven't had a look at UE4.

The one main feature that annoys me about unity is the no dynamic shadows in the free (I'm not shelling out $$$$ to do some proof of concepts).

Does UE4 have good exporting options? Phones, tablets etc?

Was nice to play something very different for the theme of aftermath. I really enjoyed the graphics and the change in portraits/sprites.

Admittedly I didn't really know what was going on for the first few minutes and for some reason my mouse was a little glitchy trying to restart when it went to game over but once I got what was going on it was great to see the amount of work put into all of the various choices.

I read the extras afterwards and funnily enough I was thinking to myself as it was ending, I bet he commits suicide. I'm glad you didn't go that route, I was glad to be proved wrong and liked the way you chose to end it.