General Projects Screenshots/Vids Thread

[interdpth]

Obvious bugs aside,

Gunship can now travel!

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

I can now start on some level design.

[Quote58]

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

[Scyzer]

I don't understand 90% of what I just watched :(

[CrAzY]

Get the fuck out. You actually got the top part of the screen to update correctly? Epic!

Or wait, I think I'm confused.  :lol:

[Mon732]

[spoiler=From the video description]Just showing off some stuff I've done recently, specifically the HUD.
This is a sprite based hud instead of the layer 3 based HUD of the original game. I styled this one similar to the HUD in Metroid fusion (the energy tanks and weapon icons).

What does this HUD do that the normal one doesn't? It allows for:
-16 bit sprites for icons/numbers/etc. (standard HUD is 8bit)
-full transparency behind icons/numbers
-as a result of the transparency, it also allows the player to see two extra lines of level data at a time, expanding the screen view vertically
-sprites can overlap each other, making things like Metroid fusion style energy tanks possible with only two tiles of gfx data instead of four or five.

Also shown is:
-automorph (aiming down into a tunnel morphs while preserving all momentum)
-separated standing/morphed palettes, allowing for a much more detailed morph ball sprite that uses 15 colours instead of a handful of colours from the standing palette (the one shown here is made to look more like the morph ball from Metroid prime while still retaining the style of super Metroid)
-various small tweaks that are part of bigger additions that weren't shown in the video (the subscreen includes the timer but not the rest of the code and changes)[/spoiler]

[Scooterboot9697]

Looks awesome. However, I have one gripe, and that is the Morph Ball animation looks a little on the slow slide. Would look better if it were sped up some. :^_^:

[sylandro]

My jaw just dropped. I was about to begin work on a transparent HUD but using BG3, but I see that you've rewrote it to work with OBJ (I think? I don't even), which looks awesome! When I read about this idea I thought it would make the game much slower.

Are you planning on releasing this a resource? I understand if you wouldn't, but seeing as I was going to try to do the same thing and you've done it better...

[Quote58]

@Scooterboot9697
I agree it's a little slow. The problem is that the morphball is a fickle part of super Metroid. The speed it animates at is a simple integer of frame delay, and currently I have it set to 3. Now, there's a couple of reasons for this.
1. boostball needs to have a smooth gradient for the charging spin (when you charge boostball, you spin in place faster and faster as the palette glow increases, until you reach the maximum, as seen in this video: https://www.youtube.com/watch?v=RhQ13UMyBoQ )
2. the difference between 3 frames and 2 frames is really significant, and in my opinion (other people might disagree) you lose a lot of the detail through motion blur

So, it's really between it being too fast or too slow, and although it annoys me a little that the animation is a bit slower than the ball's movement, I think this is the best balance I could find at the time I wrote it. The real reason there's any issue at all though is that the morph ball has such poor momentum programming. Basically it reaches max speed almost instantly, which means that it's very difficult to match animation with momentum and is, I'm sure, a reason why Nintendo went with the always animating morph ball. The reason that makes sense to do though, is that you want the morphball to move decently fast. For an example of a more complex movement system for the morph ball, play around in redesign axiel edition. Drew went to a lot of effort to give morphball more accurate speeds, and as a result more accurate animation, but very soon you'll see how much it sucks to have accurate momentum in morph ball. It makes it much harder to control and much much too slow for most of us to be comfortable with. I initially implemented a similar system, but came to the same conclusion he did, which is that it's really hard to balance and people will simply think it's slow. Unlike Axiel edition though, I decided to throw it out the window in favour of the player being more comfortable with it. Instead, I have more accurate speeds with my boostball when it's in motion, and that has a higher range of animation speeds as well.

Sorry for the long winded answer, when I made that morph code a while back I spent a long time testing and tweaking to see what worked best :lol:


@Scyzer
I'm not sure what you're saying. Do you mean like, you don't understand the purpose of things I'm doing in the video? In that case the description (which Mon helpfully posted in a reply) explains the things being shown in the video.


@CrAzY
Don't worry, that's the next step :wink:

My jaw just dropped. I was about to begin work on a transparent HUD but using BG3, but I see that you've rewrote it to work with OBJ (I think? I don't even), which looks awesome! When I read about this idea I thought it would make the game much slower.

Are you planning on releasing this a resource? I understand if you wouldn't, but seeing as I was going to try to do the same thing and you've done it better...

Thanks!

Well a transparent hud with layer 3 is actually really simple. I showed a picture of what that looks like in the ideas thread in response to someone, but I'll post it again here:
In fact it's a matter of changing a single byte. Basically the hud in super works like this:
There are 4 layers to work with. Layer 1 (solid level tiles), layer 2 (background/static layered background), layer 3 (fx/hud), and the sprite layer. However, it's not as simple as all the layers being stacked on top of each other.
The first 4 lines (32 pixels) are actually only layer 3. Essentially those first lines are 'locked' in, and drawing of all the other layers happens offset by 32 pixels down. However, if you tell the game not to lock those lines of tiles, then the level data/background will be drawn starting from where ever you tell it, and since layer 3 is transparent, as long as you are still putting the tiles into vram the hud will be drawn in the location, transparent overtop the other layers.
For reference, this is the byte to change:
org $8096A2 : LDY #$00XX
Where XX is the number of pixels downwards to lock. So if you unlocked the bottom two lines, you would write LDY #$000F instead.

However, the problem with that kind of transparency is that you get a ghostly, washed out effect on the tiles, and the tiles themselves are still restricted to being 8 bit sprites, and therefor you only have 3 colours to use for any given tile.
Now that being said, the advantage of using 8bit sprites for an hud should not be brushed off. By not having to draw the top 4 lines of the screen, super Metroid is able to lag less, and using 8 bit sprites makes storing the gfx in vram significantly easier and it allows for more sprites on screen with less lag. It also means the hud is never interacting with enemies the way it does when they're sprites (I personally like that though).
The other big advantage of using 8bit non transparent hud, is that you can have static tiles. What I mean by this is that the original hud has a bunch of tiles that are drawn onto the screen when loading the hud, but since they never change during gameplay (think ENERGY tiles), they don't need to be redrawn every frame. This saves a lot of processing, where the sprite based hud requires everything to be drawn every frame (it's on top of the level data layer after all).

I'm not sure what you mean by OBJ, by I'm assuming you mean the sprite layer, in which case yes. Not enemies though, which would be a ton more processing, just sprites.

I'll release it as a resource when it's finished and I have a way to make it more user friendly for people who don't already code (I have an hud creation tool in the works anyway, so I'll make one for sprite huds too). There's actually a lot of stuff I've made that I will release once I get around to rewriting the code and polishing things up. The code in this one is pretty good but it's not finished yet.

[sylandro]

@Quote58 By BG3 and OBJ I meant layer 3 and the sprite/OAM layer, respectively. I figured there would be lag due to the lack of DMA transfer and having to execute branching code to draw the sprites each frame. But hey, i'm surprised it works so well.

By transparent I meant editing each HUD tile to have color 0 drawn behind them, then fiddle around in bank 80 to make color 0 translucent to the other layers, and enlarging the display area of the other layers. Your bits of code have made it much easier for me to figure out where to change things. Thanks! I'll certainly keep an eye on your progress.

[Scooterboot9697]

(snip)

Ah, I see. That makes plenty of sense. I've had plenty of experience programming Morph Ball animation and movement into my GameMaker engine. However, I think it's obvious that there is a significant difference between ASM and GML.

Also, if 2 is too fast and 3 is basically too slow... There should be a way to make a compromise. A delay of 2.5 frames is adequately impossible, but what if the delay switched between 2 and 3 every time it changes frame?

Not sure how possible this is in ASM, but I used a similar method for the basic walking animation for my engine (a delay of 1 frame was too slow and a delay of 0 was too fast so I made it delay once only every other frame).

I hope I explained all that correctly.

[Quote58]

@sylandro
Well it still does use a DMA transfer, and the normal hud has branching code for what it draws each frame, so I'm not sure what you're getting at, but I was also surprised by how well it works. The only annoying slowdown I've found is once you have like, 20 etanks, then the very small lag becomes much more noticeable, since it's drawing 20+ sprites extra per frame. Other than limiting etanks or using one sprite for multiple tanks, I don't know a good way to fix that off the top of my head. In general though, it's not much of a difference in performance.

The HUD tiles all have colour 0 drawn behind them. The reason it's black is because the game doesn't draw anything there other than the sprites, so the default black background is what they are all drawn on top of.

So with regard to making the standard hud transparent, the problem is it already is. The reason there's an issue aesthetically is because of it being on layer 3. Layer 3 is subject to palette blending, which makes the tiles look weirdly see through, the way it does with fx. Problem is it makes sense to do that for rain or lava, but not for the hud. You could fix that, but it would take some real effort and require you to change how the game works with FX1 and layer 3. However, the address I gave you should be a good start to whatever you want to do with it. I'll give you another one that may help though:
org $809CAD : LDA #$00XX
Where XX is the amount of HUD data to transfer over

Good luck, and if you have any HUD related questions, I've done a lot of work on that part of bank $80 so feel free to ask.


@Scooterboot9697
Well GML is a high level scripting language, so a lot of low level stuff gets taken care of under the surface, so that it's easier to work with on top. However, most programming concepts are transferable between high and low level languages.
Now in terms of your suggestion, that's something I had thought about, but I'm afraid that it won't look right with the morph ball. As I said, it's a very finicky part of the engine, so it needs to be really smooth and comfortable for the player.
Your suggestion btw is basically the same idea as subpixels, which are used for most movement in the game. I'm not sure if that will transfer over to frame delays, but I will probably give it a shot at some point to see if I can find a good compromise. The benefit of using a 3 frame delay is that the animation is incredibly smooth, and doesn't suffer from motion blur. I really love how the gfx for this morph ball look, and it uses 8 unique frames, so I want to make sure it looks the way it should.
Thanks for the suggestion though, it's good to know someone else was thinking about that as a solution!

[squishy_ichigo]

The only annoying slowdown I've found is once you have like, 20 etanks, then the very small lag becomes much more noticeable, since it's drawing 20+ sprites extra per frame. Other than limiting etanks or using one sprite for multiple tanks, I don't know a good way to fix that off the top of my head. In general though, it's not much of a difference in performance.

How about grouping etanks into one sprite? So for instance, instead of 20 - single tank sprites, you can have a 20 tank sprite, a 10 tank sprite, a 5 tank sprite, a 2 tank sprite, so on so forth, as you seem necessary. It takes up more gfx space, but with less sprites on screen, it should be less intensive?

[FelixWright]

The only annoying slowdown I've found is once you have like, 20 etanks, then the very small lag becomes much more noticeable, since it's drawing 20+ sprites extra per frame. Other than limiting etanks or using one sprite for multiple tanks, I don't know a good way to fix that off the top of my head. In general though, it's not much of a difference in performance.

How about grouping etanks into one sprite? So for instance, instead of 20 - single tank sprites, you can have a 20 tank sprite, a 10 tank sprite, a 5 tank sprite, a 2 tank sprite, so on so forth, as you seem necessary. It takes up more gfx space, but with less sprites on screen, it should be less intensive?

It's funny that you mention that; MZM does exactly that with HUD graphics data. It's not a bad idea, until you decide to update the graphics of the tanks. From there you could be spending a good 20-30 minutes copying and pasting and rearranging.

[Quote58]

Well, not really. What You can do is simply make new OAM data for different groups using the same etank gfx.
For example you can have 2 etank sprites (1 empty 1 full), and have it do say, groups of 5, or even 10 by making OAM data that just uses the same tile 5 or 10 times.
The problem here is writing a more complex etank drawing routine that decides when to draw normal tanks and when to draw groups, and then dynamically chooses locations. That's something I can do later on to make sure it doesn't lag as much.

[Jiffy]

[spoiler]





[/spoiler]

A few pics of progress from Super Metroid: Nature!!

(the images won't work properly, so just use this http://imgur.com/a/Mpy1J )

[Quietus]

Those look like some quality vanilla rooms, Jefe. :^_^:

[FelixWright]

[spoiler]





[/spoiler]

A few pics of progress from Super Metroid: Nature!!

(the images won't work properly, so just use this http://imgur.com/a/Mpy1J )

Seriously vlads, we should all be using postimg instead of imgur.

[Cpt.Glitch]

Was waiting to put this in RotM but it has yet to be updated so here is a little bit of the "Quarantine Zone" from Insanity.
[spoiler][/spoiler]

[Quietus]

I like the palette choices, and overall the room is pretty well built.

If I had to find a niggle, it'd be the one inconsistent structure stuck in the rock on the left-hand side, since all the others are only joint to the surfaces. :heheh:

[Quote58]

Auto-morph:
https://youtu.be/VpHNv-H14aI

also, a funny effect of swapping tilemaps:
https://www.youtube.com/watch?v=3QYhuimVEBg

[altoiddealer]

Does the auto-morph work differently than in Redesign Axiel Edition (manually coded to activate at specific locations)?

[Quote58]

Does the auto-morph work differently than in Redesign Axiel Edition (manually coded to activate at specific locations)?

Yes, like I said in the description on my original video about it, this works anywhere that has tiles in the right formation. No bts or restrictions on it. If you put a solid wall with a 1 tile gap at the bottom between it and the ground, you can use automorph on it, and the same goes for the mid air morph but with a different formation obviously.

The only real restriction is with enemies, which could be handled but would be kinda weird. Super Metroid has those heads that turn to look at samus, which are enemies. But they're also used as solid tiles in a couple of places. So in those places you can't automorph because they aren't tiles. However, if it mattered much I could modify the enemy's ai to trigger it too, but since most enemies are supposed to hurt samus on contact, it would have to be a case by case basis.

You can think of this automorph as being more like what you get in AM2R.

[Scooterboot9697]

Haven't posted anything in this thread in quite some time. Been sharing a lot of my stuff in the Discord chat recently.
So, sharing this here for the peeps who do not use Discord. :^_^:
https://www.youtube.com/watch?v=8--UUAC3z-g

[FPzero]

Oh man I'm real excited to see you're still working on this! After so many months without hearing anything I was worried it had been put aside. Everything looks great of what you showed us. What's your general progress with the engine? Movement and mechanics appear to be close to finished if not already. Has there been any progress on enemy AI, item pickups or things like that?

If I had one very minor criticism, the constant breaking sound effect when you shinesparked through a large row of speed booster blocks felt out of place. Is there any way to slow down the sound effect frequency to something more like the original super metroid just so there isn't so much breaking noise in the audio when you're shinesparking? If not, as I said it's a very minor complaint.

[altoiddealer]

Damn that looks good.  Speed grapple is cool AF.