The VG Resource

That looks better, but I'm confused as to why that thing in the bottom left isn't, you know, in the bottom left...


This makes more sense to me, as the actual gameplay will be within the centre of the screen. You want to avoid anything being in the middle of the screen as much as possible, from all angles. So put things into corners.
Taking into account, you will probably never have Mario go below a certain area of the screen, and if he does, it won't be in the exact bottom left or right of a level.


Since the game scrolls, those things will never get in the way unless you literally hit the top of the screen through the use of a flying power, which could happen in SMB3 and SMW etc. - which resulted in you going out of the general "area of play" - so it's not important, because it rare that you'd need to see anything in those areas. As a level scrolls obviously Mario is in the middle of the screen, except at the start -where he will generally appear on the left. Which is where those things on the left where - which would just be irritating for level design.


If there is a hole, it'll approach from the right, and will be in the middle of the screen when it comes to jumping it, or falling down it - which means with those things in the far bottom left or right, you have more options with how low to make the ground level.


Because of the extra space from lowering the ground, you have more options of using the space above the player for flying enemies that can assist in being fucking irritating.

The Doki Doki Painc meter will only be present in Subcon-like levels or levels that have a Super Heart. Standard levels wont have the DDP health meter shown.

Yes, but placing any HUD elements in an invasive place is not a good idea. Just place it up there, presto. This way, those 'special' levels won't be as annoying and you even could stretch this kind of HP bar anywhere else as a bonus.

Goddamn there's a lot of junk in that HUD.

I wonder why some of the minimal stuff can't be shown on the start menu or something

Well all of these things have been taken care of so we have a new HUD, okay? Heres some screenies for proof:




Well, these are old screenshots, we advance pretty quickly so everything in that HUD is aligned, and there's no un-necessary space taken up. So avoid the score numbers, time numbers n' stuff sticking out.

Now I'd like some good critique on this game and not blatantly judging the sprites when you haven't played the demo yet.

Quote:I wonder why some of the minimal stuff can't be shown on the start menu or something

What "minimal stuff" are you talking about? And do you mean Start Menu by Pause Menu? That's really un-necessary, I guess you're not used to large HUDs.

(07-19-2012, 10:19 PM)Mikeystar Wrote: [ -> ]and not blatantly judging the sprites when you haven't played the demo yet.

We can only judge what you provide and being a community focused on pixel art, you have to expect that. We've had that talk already. Stop persisting on the issue. Thanks.

I'd actually prefer the score number to be aligned with the life counter instead of jumping to the left.
Either way, what exactly is the number in the lower right corner? I've been wondering for a while now.

I agree with Previous, we're judging what we can see - and we can see sprites. We can't see a demo. What do you want us to say? It looks like a game, with sprites that we can't comment on. It looks like it plays like every other Mario game/fangame.

Also agree with Previous on the score and I'd also say time, they should be left aligned.

I disagree about the score counter. But I also don't think it should stay where it is. I think it should be right aligned beneath the actual number of lives so there's room to add more numbers to the score, since we read left-to-right. Of course you could always fill in that area with 0's and then left align it.

I agree about the TIME counter, however.

Here are some more current screenies. Like I said, the screenies are posted were old, so this is the final decision of the HUD.





Currently in these screenies you see the Super Heart in the first screenie, Mario playing a minigame that is a WIP, and Mario riding the carpet while stunned from when he grabbed the Super Heart

Well thanks for your feedback guys, this is the final In-Level HUD and I won't be making any more adjustments to it unless more gimmicks in levels are featured.

As an extra, here is a screenie of the Mapscreen, it has SMB3 and SMW Elements combined!

(07-20-2012, 02:28 AM)Previous Wrote: [ -> ]

(07-19-2012, 10:19 PM)Mikeystar Wrote: [ -> ]and not blatantly judging the sprites when you haven't played the demo yet.

Either way, what exactly is the number in the lower right corner? I've been wondering for a while now.

Previous, the numbers on the bottom right of the screen is FPS (frames per second). It tells you the speed of which the game is playing at. FPS that is at 50-60 FPS means that its running at optimal speed, and the lower the FPS, the lag becomes more apparant as the game's slows down (as the FPS lowers)

(07-20-2012, 12:51 PM)sspp03 Wrote: [ -> ]Previous, the numbers on the bottom right of the screen is FPS (frames per second). It tells you the speed of which the game is playing at. FPS that is at 50-60 FPS means that its running at optimal speed, and the lower the FPS, the lag becomes more apparant as the game's slows down (as the FPS lowers)

It does appear to be that way. It might be something worth looking at, though. If the game is running at 60 (which I assume it is, since the standard is usually 60 or 30, and two of those counts are above 30), then 31 and 39, etc. are unreasonably low. Even then, a low FPS is tolerable, but not a fluctuating one. At most you want it to change by 3 or 4 FPS while playing the game. 8 - 10 is really bad. Try optimising some stuff.

(07-20-2012, 05:32 PM)Hoeloe Wrote: [ -> ]

(07-20-2012, 12:51 PM)sspp03 Wrote: [ -> ]Previous, the numbers on the bottom right of the screen is FPS (frames per second). It tells you the speed of which the game is playing at. FPS that is at 50-60 FPS means that its running at optimal speed, and the lower the FPS, the lag becomes more apparant as the game's slows down (as the FPS lowers)

It does appear to be that way. It might be something worth looking at, though. If the game is running at 60 (which I assume it is, since the standard is usually 60 or 30, and two of those counts are above 30), then 31 and 39, etc. are unreasonably low. Even then, a low FPS is tolerable, but not a fluctuating one. At most you want it to change by 3 or 4 FPS while playing the game. 8 - 10 is really bad. Try optimising some stuff.

The ASETeam is well aware of the problem of the lag seen in Super Mario World: All-Star Edition. Mikeystar is currently finding ways to reduce the lag and to optimize the FPS of the game. Converting .mp3 files (MPEG-3) to .ogg files (Ogg Vorbis) is one of our agendas to reduce the lag and file size. Two nights ago from this post, I was on IRC chat in the SMWASE forum suggesting to externalize the backgrounds used in SMWASE and to delete unneeded backgrounds in the game's dev source (a dev source is a privately-owned and distributed .gmk file).

(07-22-2012, 08:57 AM)sspp03 Wrote: [ -> ]Two nights ago from this post, I was on IRC chat in the SMWASE forum suggesting to externalize the backgrounds used in SMWASE and to delete unneeded backgrounds in the game's dev source (a dev source is a privately-owned and distributed .gmk file).

May I point out that I'm a game developer, and that won't boost the FPS. Lower the filesize, yes, but not boost the FPS. Filesize is less of an issue, to be honest.

To boost the FPS, you need to optimise the code. Are you running hundreds of different checks when you only need one? Are your loops terminating properly? Are you calculating things multiple times when you could just store the value in memory? Things like that are what you need to consider. Optimisation isn't about deleting resources, it's about going through your code and making lots of fine adjustments to ensure that the code runs at its maximum potential. It seems to me that you haven't done a particularly good job. Such a variable frame rate may imply that you don't have very good garbage collections, which will reduce available memory for computation and storage, and possibly cause crashes if you leave the game on too long. I'd seriously consider looking through the code very critically. If it's running that slowly though, it might be worth starting from scratch and paying more attention to how the code is structured (which I've done before more than once).

(07-22-2012, 01:39 PM)Hoeloe Wrote: [ -> ]

(07-22-2012, 08:57 AM)sspp03 Wrote: [ -> ]Two nights ago from this post, I was on IRC chat in the SMWASE forum suggesting to externalize the backgrounds used in SMWASE and to delete unneeded backgrounds in the game's dev source (a dev source is a privately-owned and distributed .gmk file).

May I point out that I'm a game developer, and that won't boost the FPS. Lower the filesize, yes, but not boost the FPS. Filesize is less of an issue, to be honest.

To boost the FPS, you need to optimise the code. Are you running hundreds of different checks when you only need one? Are your loops terminating properly? Are you calculating things multiple times when you could just store the value in memory? Things like that are what you need to consider. Optimisation isn't about deleting resources, it's about going through your code and making lots of fine adjustments to ensure that the code runs at its maximum potential. It seems to me that you haven't done a particularly good job. Such a variable frame rate may imply that you don't have very good garbage collections, which will reduce available memory for computation and storage, and possibly cause crashes if you leave the game on too long. I'd seriously consider looking through the code very critically. If it's running that slowly though, it might be worth starting from scratch and paying more attention to how the code is structured (which I've done before more than once).

Same here, I've done this more than once. I don't really think it's lagging issues though, I get a reasonably good frame rate when I play the game. I think it's the loading time though. 20-40 FPS is what I normally get. We've restarted ASE's progress dozens of times due to this problem. The latest ASE Source has improved on the code and the computations are getting much better than they were since we first started.

And yes, you are right about reducing the file size. sspp03 was wrong about that one. We're still making adjustments here and there so the FPS can go higher than it used to be.