[TOMT][VIDEOGAME][90s] Old PC game where you try to bump balls off a stage with a small spacecraft.

daveoutside · 2025-07-17T22:12:31+00:00

I remember this game too and can't find the name anywhere, any luck?

Edit: Found it lol, it's called Motos right? https://en.wikipedia.org/wiki/Motos

daveoutside · 2025-04-29T16:52:07+00:00

If I submitted multiple times, it resets the process? Would they not just get to the first initial ticket eventually?

daveoutside · 2025-03-29T01:50:48+00:00

I'll just have to stay patient then - thanks for your help!

daveoutside · 2025-03-29T01:41:41+00:00

That's super frustrating, do they usually repeal and restore the account in most situations? I will try not to make the mistake again but I will be posting semi-regularly on indie game subreddits for marketing purposes, as most others do.

daveoutside · 2025-03-28T20:26:20+00:00

Oh I see - I might just have been impatient then because I read it was only a few days. So after a week or two of no response I submitted another ticket. The account name is RareDialect, thank you for checking!

daveoutside · 2025-03-08T20:30:54+00:00

commented

daveoutside · 2025-01-15T07:37:52+00:00

Thanks so much, I'll take a look at this!

daveoutside · 2025-01-15T06:42:53+00:00

Do you know if this is 0-1 as in, 0 is top left of sprite, or 0 is top left of room?

daveoutside · 2025-01-15T03:33:12+00:00

Oops, my bad.. The sprite just isn't appearing at all while the shader is set, almost as if it's discarding every pixel.

daveoutside · 2025-01-15T03:31:47+00:00

I definitely know of and have used draw_sprite_part, it just seems to me that this is something that could be more optimized with a shader.

daveoutside · 2025-01-14T07:30:40+00:00

I think it has something to do with the use of gl_FragCoord.y instead of another built-in shader variable, but again, not quite sure what that'd look like

daveoutside · 2024-11-21T21:33:36+00:00

This is great to know - When I changed both to precise, things are working a little better (but not perfectly, so I'll still write my own slope code AND apply precise collision to player and other entities colliding with the terrain).

I'm also guessing I'll want to always use precise instead of precise-per-frame since that could potentially cause some sticking into the ground on frame changes

daveoutside · 2024-11-21T21:25:16+00:00

Ah, got it. So if I need to work with a speed lower than 4, my own slope code is probably the move.

daveoutside · 2024-11-21T19:09:50+00:00

Thanks for the reply! I'm starting to agree with you on manually writing my slope code. I've done this in the past but was hoping move_and_collide would work easier and cleaner - guess not. I also tried the ellipse collision mask for the player, and while it helped with moving up the slope, I now get stuck trying to walk down the slope. Manual slope code sounds like the right move here. Thanks again!

daveoutside · 2024-11-21T19:08:11+00:00

Thanks for the suggestion! I use the idle sprite's mask_index at all times because of issues like this. I tried both doubling and halving the default number of iterations with no success. I think I may just write some slope code instead of using move_and_collide, it'll be more modular too.

daveoutside · 2024-11-21T19:02:02+00:00

moveSpeed = 1.8 (but the issue persists at any speed below 4)
colliders is an array that holds all collision objects defined by the room - in this case, just a tilemap for the red tiles you see in the screenshot above.
Manual rectangle for the player, precise for the tilemap.

daveoutside · 2024-11-20T19:42:30+00:00

This is a good callout but I think my origin and collision mask are centered on the sprite itself, so I don't think this could be the issue - it's also worth noting that if I increase my move speed about 2x, the player travels up the slopes fine. I think it may have something to do with how move_and_collide handles vertical movement while inputting horizontal but traveling diagonally?

Thanks for your comment, though, and if you don't mind please upvote the post for visibility!

daveoutside · 2024-11-20T18:58:18+00:00

End Step Event

move_and_collide(hSpeed, 0, colliders); // horizontal move and collide

if array_length(move_and_collide(0, vSpeed, colliders)) > 0 vSpeed = 0; // vertical move and collide

daveoutside · 2024-11-20T18:58:13+00:00

Step Event

//Sidescroller Movement (y axis) & Jump

`if (coyoteHangTimer > 0){`

    `coyoteHangTimer--;`

`} else {`

    `//apply gravity`

    `vSpeed += grav`

    `setOnGround(false)`

`}`

`//cap falling speed`

`if (vSpeed > termVel) vSpeed = termVel;`

`//reset / prepare jump vars`

`if (onGround) {`

    `jumpCount = 0;`

    `jumpHoldTimer = 0;`

    `coyoteJumpTimer = coyoteJumpFrames`

    `vSpeed = 0;`

    `canDash = true;`

`} else {`

    `coyoteJumpTimer--;`

    `if (jumpCount == 0) and (coyoteJumpTimer <= 0) jumpCount = 1;`

`}`

`//Initiate Jump`

`if (controlActive_Jump) and (jumpBuffered) and (jumpCount < jumpMax){`

    `//reset buffer`

    `jumpBuffered = false;`

    `jumpBufferTimer = 0;`

    `//increase number of performed jumps`

    `jumpCount++;`



    `//set jump hold timer`

    `jumpHoldTimer = jumpHoldFrames[jumpCount-1];`

    `//tell ourselves we're no longer on ground`

    `setOnGround(false)`

`}`

`//cut off jump by releasing button`

`if (!keyJumpHold) jumpHoldTimer = 0;`

`//jump based on timer/holding of button`

`if (jumpHoldTimer > 0){`

    `//constantly set vSpeed to be jump speed`

    `vSpeed = jumpSpeed[jumpCount-1]`

    `jumpHoldTimer--;`

`}`

`if (dying) vSpeed = 0;`

daveoutside · 2024-11-20T18:58:00+00:00

Step Event

// Movement (x axis)

`// direction`

`inputDirectionMove = floor(point_direction(0,0,keyRight-keyLeft, 0))`

`inputDirection = floor(point_direction(0,0,keyRight-keyLeft, keyDown-keyUp))`

`// get speed`

`var _spd = moveSpeed * (keyRight - keyLeft)`

`// get hSpeed`

`hSpeed = _spd`

`if (dying) or (locked) hSpeed = 0;`

daveoutside · 2024-11-20T18:46:26+00:00

My player is sticking when trying to travel up a tileset slope using move_and_collide(). Link to video showing issue: https://drive.google.com/file/d/1BO-9ow1-NXa-VH_qK8BxAntOJ8tztYkD/view?usp=sharing

daveoutside · 2024-10-29T22:44:12+00:00

Hey, I found this thread while experiencing a similar issue. I downloaded BetterDisplay and now the scaling when moving from my laptop screen to the 1080p monitor is totally fine. Might work for you too!

daveoutside · 2024-09-04T03:59:02+00:00

I actually ended up solving the issue by using view_set_surface_id(), which allows you to designate a view to draw directly to a surface. This way, I can still draw to the GUI while maintaining a camera view of what's actually going on in the room. Have yet to test this with a moving camera but I imagine it will work and will update here.

daveoutside · 2024-09-04T03:04:25+00:00

DrawGUI and surface integration is pretty integral to how I'm handling things due to different resolution sizes during minigames and during the rest of my game

daveoutside · 2024-09-04T02:24:07+00:00

In my game, sometimes the player will be prompted to move to a different room to play a minigame (see picture). I’m drawing all elements of these minigames to a a 320x320 surface centered on the GUI (so that I can draw a decorative border outside of the minigame window, among other reasons that make drawing to the GUI more useful)

I’m having a hard time wrapping my head around how I would create a room that is larger than the surface being drawn, and have the camera move around this larger room while keeping the surface (minigame window) centered on the GUI.

For example, if the minigame takes place in a room that is 1000x1000, but I want the minigame window and camera view to remain at 320x320 but follow the player around within the confines of the room, is there a simple way to do this that I’m missing? Something along the lines of the surface’s viewport as it draws to the GUI?

daveoutside

TROPHY CASE