Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
rogueyoshi wrote:
[...]i think this belongs in the snes games section.
I agree, and I've moved it here.
EDIT:
Re the hack itself, it's just one of those generic high difficulty hacks. While a run of something like this would be good for showcasing glitches, I'd much prefer to see that done in the context of levels meant for actual normal game play - say, in a 96-exit run or a 120-exit Super Demo World run.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Dooty wrote:
The PlayStation BIOS name is derived from the console model, like the SCPH1001, SCPH7502 etc.
There's no PlayStation model (U) (v4.1). My guess is that he is using a normal BIOS with a fancy name.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
arukAdo wrote:
Because using the 1001 (default one used by ALL our movies) result in different timing, this would be the only reason, else you have to specify in rules you can take ANY bios and its going to be the fuck fest to know what bios is faster than the others, just to whore on few frames
In the future, we should mandate one (I believe it's been brought up on IRC that an exception would be made for this run since there's no official line on the issue at the moment).
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
This gets a Meh from me. The commentary did indeed make things more interesting, but it seemed to me that around 90% of the game play was walking (and/or jumping) back and forth.
That having been said, it does improve a previously published run and people seem to enjoy it, so I suspect it will end up being published anyway. Congratulations.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Aktan and I are actively working on this, so don't worry too much. (Do continue experimenting if you already are; it might take a while for this to go anywhere before one of us has something worth uploading.)
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Warp wrote:
2) Give an example code where using static_cast gives a compiler error,
while using dynamic_cast compiles and works ok. The only difference between
the two cases is the keyword, otherwise the codes must be the same. Also
explain why this is so.
(And no, this problem does not involve precompiler macro trickery or
anything of the sorts. That's not what this problem is asking. It's about
the semantics of static_cast vs. dynamic_cast.)
Just had to tackle this one - it reminds me of working with a particularly nasty class hierarchy once where I needed to put this knowledge to use.
#include <iostream>
class typeA {
public:
virtual void someMethod() {
std::cout << "typeA" << std::endl;
}
};
class typeB {
public:
virtual void someMethod() {
std::cout << "typeB" << std::endl;
}
};
class typeC : public typeA, public typeB {};
int main(int argc, char** argv) {
typeA* foo = new typeC();
typeB* bar = dynamic_cast<typeB>(foo);
if (bar) {
bar->someMethod();
} else {
std::cout << "foo is not typeB" << std::endl;
}
delete foo; // not strictly necessary, but I want to set a good example
return 0;
}
If you replace dynamic_cast with static_cast, you get
example.cc:22: error: invalid static_cast from type ‘typeA*’ to type ‘typeB*’
Note how typeA and typeB are, outside of typeC, unrelated. This is why static_cast throws a compile error - the two classes aren't directly hierarchically related to one another, so it's not possible to cast up or down in the fashion that a static_cast would need.
(The explanation sucks and doesn't really do the concept justice, but the example's there if someone wants to explain it better. When I don't need to run off to be somewhere in 10 minutes, perhaps I'll come back and flesh this out further.)
Thanks for linking to that and proving my point. Although the second part of that run is impressive, one needs to sit through the hideously slow first part in order to get there. I'd probably vote Meh on this if it were submitted.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
GGG wrote:
I am also interested to encode movies, because I have a problem with that
Have you read the Encoder Guidelines? It is a good place to start for this sort of thing. If you have more specific problems, you could ask them in the Sites forum or perhaps the Newbie Corner.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
andrewg wrote:
I'm curious... can't 1 block gaps be walked over with samus and save time by not jumping? I thought I remembered this being the case.
Nope. You'll hit the edge.
Also, that's not jumping per se; it's using the morph ball and unmorphing quickly, which bumps Samus up a few pixels (this is the basis of the door glitch) and therefore minimises the amount of time spent in the air.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I'll admit it - part of the reason the predecessor to this exists was in anticipation of seeing this run made. I'm glad it had the intended effect.
I had wondered if this route might end up being faster overall, but ended up dismissing it on account of the larger distance involved; it never occurred to me (even after the post-Kraid sequence) that having missiles would save so much time. Seeing the Multiviola room trashed is definitely worth it.
I'm glad there was an excuse to use the Kraid door glitches here; it deserves a place in another run.
Also, I discovered a new luck manipulation technique? News to me. I guess I got lucky. :p
In case it's not obvious by now, yes vote.
Encodes in the pipes - there will be a version without the commentary and a version with the commentary.
EDIT:
Encode (with soft subtitles, as suggested on IRC): http://www.archive.org/download/NesMetroidByLordTomIn1108.78/metroid-tas-lowp-lordtom.mkv
Here's a no-subtitle version on DM: http://www.dailymotion.com/video/xbw7g6_nes-metroid-low-in-110878-by-lord-t_videogames
And with subtitles (as shown in FCEUX) on DM: http://www.dailymotion.com/video/xbw7v2_nes-metroid-low-in-110878-by-lord-t_videogames
EDIT2: archive.org has updated the mkv now.
EDIT3: fixed broken link.
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
As it happens, I have an XP VM in VirtualBox (host machine runs Gentoo Linux), and FCEUX runs fine in it. Can you dig a little deeper into the error dialogue you get and see if you can turn up more information? (Those normally provide more technical details surrounding the crash, IIRC.)
Emulator Coder, Experienced Forum User, Published Author, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
If the run's not done, there's no point in letting the credits run; just skip them.
If there is a faster order for completing the extra levels, I'd prefer to see that, though I suspect there's negligible time gain there compared to the time taken in selecting the levels.
As to what to do after the last level, I would personally prefer to end the run at the moment of completion of the last level.
