General Projects Screenshots/Vids Thread

[Quietus]

I'll iterate what I said above: It'd be great to see some TAS use of this, perhaps even applied to the original game. Beeline for Speed Booster, then spark and speedball the remainder of the game. :grin:

[Zero One]

It has been a long time since I last worked on MonoTroid, but in the space of about a week, I've implemented quite a few things that I hadn't even worked on before. Here's a gif nicely demonstrating everything:





The first thing was resolution independent scaling. Originally, MonoTroid rendered at 256x224, which is really small. Now, it still is doing that, except it's capable of scaling that screen up to any resolution you want. The image above is it scaled to 1024 x 896. Unfortunately, changing the aspect ratio will cause the game to stretch instead of letterbox, so I'll need to sort that later.


The second thing is actually having a camera. Before, the entire world could only exist in that 256x224 space. Samus could walk outside of that, but the game didn't have the concept of a camera, so Samus would just walk offscreen. Now, I have a proper camera that uses matrices to track a target object, which is Samus in this case. It also uses the matrix produced by my resolution code, so it scales properly, and tracks!


Third, and most significantly, the slope collision. Initially, the slopes were special cases, where the code would try and snap Samus to the gradient of the slope, depending on how far she moved along the slope. It kinda worked, but the fact that slopes are considered a special case was awful, and had so many caveats attached that I'd need even more special case code. Instead, I swapped to a solution that uses polygon collision. The separating axis theorem is used to determine if there's a collision, and provided an amount I need to move Samus by to snap her to the point of collision. The result is that my entire collision-resolving routine went from 44 lines of code to 7!


I still have a lot more work to be done, like tidying up the code, optimising it and fixing a few problems that you can probably already see in the GIF, but this marks a pretty large jump in what I'm able to do, and I'm really happy with what I've achieved here!

[liamnajor]

[spoiler]

It has been a long time since I last worked on MonoTroid, but in the space of about a week, I've implemented quite a few things that I hadn't even worked on before. Here's a gif nicely demonstrating everything:





The first thing was resolution independent scaling. Originally, MonoTroid rendered at 256x224, which is really small. Now, it still is doing that, except it's capable of scaling that screen up to any resolution you want. The image above is it scaled to 1024 x 896. Unfortunately, changing the aspect ratio will cause the game to stretch instead of letterbox, so I'll need to sort that later.


The second thing is actually having a camera. Before, the entire world could only exist in that 256x224 space. Samus could walk outside of that, but the game didn't have the concept of a camera, so Samus would just walk offscreen. Now, I have a proper camera that uses matrices to track a target object, which is Samus in this case. It also uses the matrix produced by my resolution code, so it scales properly, and tracks!


Third, and most significantly, the slope collision. Initially, the slopes were special cases, where the code would try and snap Samus to the gradient of the slope, depending on how far she moved along the slope. It kinda worked, but the fact that slopes are considered a special case was awful, and had so many caveats attached that I'd need even more special case code. Instead, I swapped to a solution that uses polygon collision. The separating axis theorem is used to determine if there's a collision, and provided an amount I need to move Samus by to snap her to the point of collision. The result is that my entire collision-resolving routine went from 44 lines of code to 7!


I still have a lot more work to be done, like tidying up the code, optimising it and fixing a few problems that you can probably already see in the GIF, but this marks a pretty large jump in what I'm able to do, and I'm really happy with what I've achieved here!

[/spoiler]
Nice! I want to take a look at the way you resolved sloped collisions, so I can maybe add something similar to my engine. could you send me the file or code snippet in .txt format?

[Quietus]

It takes a second to stop yourself from focusing on Samus, and watching the hitbox instead, but it all appears to be working well. :^_^:

[Zero One]

Yeah, at the moment, Samus' graphics are being drawn starting at her X/Y position. Problem is, if the frame you're drawing has a lot of empty space on the edges, some frames can appear to be almost entirely disconnected from her actual hitbox. That's solved by a simple offset per animation strip, but I haven't been focusing on the animation so much yet.

[altoiddealer]

Sprite replacement of Luigi from SMB2  :lol:

[Quote58]

https://www.youtube.com/watch?v=Btbfu43MeZc

[Quietus]

The morphing is the coolest thing in the video. It could make a number of hacks much more accessible for less experienced players.

[MollyAncalime]

What's up with the missile counter...?

[SirAileron]

What's up with the missile counter...?

It's showing Samus's state/pose ID.

[Quote58]

Yes it was showing the current pose (0A1C) for debugging

Also thanks quietus, I'm hoping to make movement much smoother and accessible in general.

[Quote58]

So I made a thing where rain drops get spawned randomly on solid surfaces with air above them.
The rain is kinda hard to see since I left the colour blend the same as the water it was previously, but trust me there's rain in the room
https://www.youtube.com/watch?v=a87w1P_rtjs&feature=youtu.be

[Quietus]

Hmm, I like the idea, but the randomness seems more odd than anything. Perhaps it'd work better if there were three (or more) variations on the drop animation, just for horizontal variation, as in left, right, and middle of a tile, and all tiles 'in the open' would have the splashing?

[personitis]

I'm a sucker for small details like that, Quote. What are the concerns with upping the number of drops spawned on screen/at once?

[Quote58]

I'm a sucker for small details like that, Quote. What are the concerns with upping the number of drops spawned on screen/at once?

Having rain on every surface would likely cause some slowdown, and the routine would have to look at every block in the room on the screen instead of just looking at the block with a given randomly found x/y, which probably wouldn't cause too much extra processing but add in enemies and other sprites and I imagine it would get too busy too quickly. Also, having that many sprites on screen uses up OAM space, so even if the processing were okay it would limit how many enemies and sprites could be on screen.

Anyway, the other day I made a preliminary homing missile (based on the proof of concept Black falcon made a while back):
https://www.youtube.com/watch?v=sOlBIJCR83E

Basically the missile looks for enemies on screen in the direction samus is facing (will probably make it more specific to which direction samus is aiming actually), and then saves the enemy index as a 'target' for the missile to use in it's running ai, where it then seeks out the target, and adjusts it's movement depending on it's angle with the enemy (similar to the item drops in the new tractor beam).

I've improved it since the video, and am working on making the missile use graphics for extra angle degrees (normal missile graphics only have 3 angles, so I'm working on having it incorporate more). Other things that need to be improved: smoother movement that doesn't instantly change direction, better handling of target indexes in ram, speed that increases and decreases depending on various factors.

It'd also be pretty easy to turn this into full on seeker missiles (charge up missiles, set targets by aiming at them (which would also draw a target over the enemy graphics), and then when released releases as many missiles as targets), however super Metroid is much more fast paced than prime, with enemies that only take a few shots to kill, so it'd be awkward to use in practice.

oh and here's a visual example of the target system:
https://www.youtube.com/watch?v=EZD1fVEQzOU

[Scooterboot9697]

Just a little sneak peak of what I've been working on.
(It's a mod for a game called Terraria for those who don't know.)

[Hackmi]

That looks awesome!
You made the samus sprite???

[Scooterboot9697]

That looks awesome!
You made the samus sprite???

No, someone else made it.
If you think I have any artistic skill, you have been mislead.

[Hackmi]

Haha, I thought the same. Seriously though, just practice, start with some Metroid two edits they are fun.

[Cpt.Glitch]

https://youtu.be/o574IWuLGvg

[A Dummy]

That's pretty cool, I liked the upgrading missiles from Metroid Fusion so it's great seeing that same idea working in Zero Mission. (Just as long as it doesn't come with an Ice Missile "upgrade" that makes them have to 2-shot weak enemies. :P)

[Zero One]

Thanks to a suggestion on my Twitter, I'm making a small game called Nade-A-Mole; whack-a-mole with grenades! Spent a couple of hours working on a disintegration effect for when the moles get hit. I think it looks pretty good!

https://www.youtube.com/watch?v=IwZ3Unn5SvM


Spent a bit more time today on a particle effect for the moles too, though that's not in this video.

[Black Falcon]

Thanks to a suggestion on my Twitter, I'm making a small game called Nade-A-Mole; whack-a-mole with grenades! Spent a couple of hours working on a disintegration effect for when the moles get hit. I think it looks pretty good!

Spent a bit more time today on a particle effect for the moles too, though that's not in this video.

That really looks like a lot of work. I've been messing with Materials in UE4 and all I've managed to do was to make things glow/flash over time....

Though that reminds me of a thing I did a while ago in UE4 as well:

http://www.youtube.com/watch?v=kh9r1GiC80U


As the title suggests, VERY barebones. I'm not working on a Prime clone, I just used this to get to know how the engine works, and how to implement a projectile system using structs, data tables and actors!

[Zero One]

That looks awesome! If you ever want help with UE4, please ask; I'll be happy to help. I'd also really like to see the particle system for the wave beam. It looks amazing!

[Cpt.Glitch]

More ZM things
https://youtu.be/Iqp12bbHclU