Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Managed to finally watch this one last week. This was great. One thing I did not fully understand that wasn't covered in the notes is the apple key in your inventory at the end that you stole from the training hall at the beginning. Couldn't the roller room in dungeon 4 be done in a way where the apple key in that room could be skipped to use the one you already have saved time?
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
I have been waiting since the announcement in the Illusion of Gaia thread. Very happy to see this completed.
Absolutely a yes vote.
By the way, some of the sprite overlap during the left+right stuff look more horrifying than the monsters in this game.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
ais523 wrote:
Although I'm not 100% sure, I think that input on DOS uses a maskable interrupt rather than polling, i.e. it actually interrupts the processor in much the same way that, say, vblank would on a NES. That means that if you press a key, it's handled as soon as the keyboard manages to communicate that fact to the processor – there's no "poll once a frame" or equivalent. The limiting factor on luck manipulation speed is therefore the rate at which the keyboard is able to send the "a key was pressed" message.
That sounds correct, input was usually handled by a PS/2 chip (e.g. Intel 8042, but this is newer). Which was usually routed directly to the I/O port interface of the CPU.
See https://wiki.osdev.org/I/O_Ports and https://www.dosdays.co.uk/media/intel/Intel%208042.pdf
This was standard input processing on x86 before USB took over keyboards and mice/mouses.
feos wrote:
Is there any info on how often this happens?
This would depend entirely on the speed of the processor and how much higher-priority load it's under.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
ais523 wrote:
There are plenty of alternatives nowadays, such as bubblewrap and AppArmor, although I haven't experimented with these myself.
At least AppArmor is a Mandatory Access Control framework and not a namespacing approach to sandboxing, it's more of a security tool than something useful for these kinds of things.
------------------------------------------------
I'm a bit short on time today so I will just dump some stuff I wrote on IRC when feos pinged me about your thread.
20:27 < Warepire> Yeah, time-keeping and memory management were the 2 major things that really killed off Hourglass. I wonder if a custom KVM driven
solution would work rather than docker containers.
20:29 < Warepire> The KVM kernel interface is surprisingly "easy" (in regards to how a full-fledged VM API can be easy), and as long as the
licensing in terms of software is managed properly, we can probably leech of QEMU KVM backend for a lot of the code that doesn't
need custom handling.
20:33 < Warepire> Either way, VM route or Docker route, there would need to be some support from TASVideos to provide the "base OS", so that the
environment is preserved.
20:34 < Warepire> For Docker it would be rules for Dockerfiles, and hosting a so called registry. For VMs it would probably be hosting custom
install medias or disk images.
20:34 < Warepire> (not including the games, obviously)
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Wooo, it's finished! Fantastic work, and I'm really glad my and Noxxas scripts were useful.
There were so many highlights in this TAS that it's practically all highlights. The way the bosses were dealt with was really funny, specially "Guess Who Needs A Kick Start" and the Yosemite Sam fight in "What's Up, Dock?".
Absolutely yes.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
I never understood how to use that feature, so I personally won't miss it. I just used the userfiles way when I wanted to share .wch files, and the bonus of that is that you can also share useful example movie files and lua scripts as well for anything that's useful to explain on a game page.
Will RAM addresses of value be exported to .wch files and uploaded to userfiles or somewhere else before they are removed?
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
I wish them luck.
The main issues that comes with re-recording is time handling and memory management. The first is just a complete mess due to the number of ways it can be done, and all of them have various quirks that translate to "well, you're not getting exactly what you asked for" and if you try to implement it in the way it's asked for, everything will go absolutely crazy, figuring out a valid timer resolution on top of that so game frame rates end up as expected isn't anywhere near trivial either, because you can't use any form of window drawing as a hook to advance time, as many games start counting time long before they create their first window. And the memory management is actively fought by Windows itself and its layers and layers of compatibility shims that causes their debugger events to severely lie to you, making you unable to (easily) get any stable tracking in place.
The latter point is what caused Hourglass to ultimately fail as a project, no one who actively worked on it wanted to deal with it. The first point we didn't even start dealing with, we just knew it was broken with its "tie the clock to the drawing calls" approach.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
I have waited a long time for a Wipeout TAS. For me this is the hardest of the Wipeout games on the Playstation (I never played Wipeout 64), seeing it played at this level was awesome. I usually prefer watching Wipeout in a 3rd person view rather than 1st person, but this TAS is still a great time.
Definitely entertained, a yes vote from me.
If you make more TASes of Wipeout, and maybe even Wip3out, I would definitely look forward to them.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
The games puzzles (based on the non-TAS playthrough) are a bit trivial for the TAS to be really entertaining when it manages to break them. But it was short enough to not be boring.
Going to have to be a Meh vote from me.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
The videos are getting crazier and crazier:
https://www.youtube.com/watch?v=B-EtjEDUWvc
Is it within the rules to allow these replays to be submitted here? (Assuming the Trackmania people would like to)
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
ThunderAxe31 wrote:
First of all, it would be mandatory to maintain BizHawk 1.x versions for XP/32bit compatibility. And regardless, let's first see how it goes for VBA-rr. There is no need to rush about this, while on the other hand it would be wise to make sure we're meeting the user's necessities.
How relevant are 32 bit systems today? Even linux distros are dropping support. And anyone running XP should really not let their computer on the internet anymore, even most modern security software won't run on XP, so anyone with such an installation today that can reach the internet should just assumed it's been compromised.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
I used to play the flash version (N) quite a lot when I was younger so I was really excited to see a TAS of the DS version.
And ... My favorite exploitable things about N aren't in N+, like angle abuse to go through one-way walls the wrong way, or using the springy blocks to catapult. The TAS is really well done for the levels it was given, but those missing things in the DS version of the game dragged the entertainment down for me from what it could have been.
I'll still give it a yes though.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
AleMastroianni wrote:
Ah, apologies! The link should be available to be seen by everyone now, let me know if that's not the case, anyway, here's a pic of the current route
Now it's all good. And permissions look correct to. Thanks!
I'm happy the script is useful. Mostly thanks to Noxxa that it exists.
I really enjoyed that short WIP, very well done! Here's hoping that Nymashock gets finished up and merged.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
AleMastroianni wrote:
I've been working on routing and effectively researching the game physics to the best of my ability in the past year or so - while also TASing the game from scratch a few times; also the normal carrots route, including the latest skips, is completed and adjusted for optimal tas movement: https://docs.google.com/spreadsheets/d/1d91NUBHgrhf5cmwKnDVsUyrlW_nzvQcZGwcKO9ugae0
Yay, progress! Looking forward to seeing WIPs if you want to post them on occation.
By the way, your google docs document requires an account (at least) to view. Is it possible to make it readable for anyone?
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
adelikat wrote:
but I don't even know of a single site other than TASVideos that uses them in a legal way.
A lot of Linux distros still use torrents as one of their delivery methods.
That said, I haven't used torrents for years, and never needed them here at TASVideos.
I do believe archive supports resume, so tools like JDownloader should work just as well as torrent clients, as that doesn't mess up as often as browsers do with resume:able downloads.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Software developer as well, different field from p4wn3r.
(I am mostly posting this to show that software development has different areas with different challenges)
I work with embedded systems, meaning that the products are not just software, but a physical device as well. This changes the aspects a little bit:
1) You don't write just one program, there's usually a whole bunch and they interact with each other.
1b) Most of those programs will usually be relatively simple
2) You will encounter OOP, but most of it is going to be of the level you described in your original thoughts about when OOP makes sense.
3) You will be integrating and debugging a lot of others code, sometimes more so than writing your own.
4) You will dive into several programming languages. (So far for me it has been C, C++, Python and some Assembly, but languages like Go and Rust are making a strong entrance, and I am sure I one day will encounter Lua as well)
4b) You will dive into several ways of compiling stuff
So, what usually happens is that a customer needs a device, they have a set requirements for the device. My task (together with my co-workers) is to get the software in the device to make the device do what the customer needs it to do.
The problems we face when working on this are somewhat like p4wn3rs problems, in that they are "dumb" problems unless you manage to land a job in research. The major change is that most embedded devices can't go around doing distributed work because data plans are expensive and a recurring cost for your customer, however, this also affects the problems you are presented with in the sense that they often don't require a lot of complicated computations.
Sometimes you need to do things from the ground up because the pre-existing solutions are either too expensive, written in a language you cannot use in the product (reasons vary from product to product), or it's open source with a license that you cannot put in your product (but you are rarely the one that has to understand the legalese, there's other people for that in these companies).
There will be less explaining to non-technical people, you will mostly be talking with your co-workers (who are working on the same embedded systems as you are) and engineers from other companies for both hardware and software when you need help using something and you cannot work it out yourselves. There will still be some explaining to non-technical people, but most of the time those things are handled by someone else.
Caveat: None of the systems I work with come with a Display. I have no idea if systems with a Display changes the outline I gave above or not.
The above also changes the questions:
1) Are you interested in solving problems with varying and changing difficulty? (sometimes easy, sometimes hard, sometimes they change shape as you go)
2) Are you willing to go on a lot of adventures? (You will be encountering technologies you're not familiar with, and need to read documentation, you may not enjoy these technologies)
3) Are you willing to have days when you are absolutely stumped over why something isn't working and getting no feedback, sometimes feeling like you're making reverse progress?
4) Are you willing to work close to hardware, and deal with bugs that may be caused by hardware design? (not necessarily a broken design, but quirky)
5) Are you willing to work in a field that very often have VERY hard deadlines? (you often need to put a product on the market before a certain date to be at all viable)
I fondly remember one product where we had power saving requirements that required us to turn off a device on PCI Express when we didn't use it, and the PCI Express controller didn't support hotplug (meaning once the device removed, it cannot find the device again without a reset). So I had to figure out how to make the driver for the PCI Express controller reset the controller before we powered on the device without rebooting the system, which was the only way the operating system in the product could reset the PCI Express controller. I liked that challenge because it was the first time we had done a product with PCI Express in it.
Those sort of challenges are not that frequent, there are also a lot of "When X happens, make product do Y", and lots in between.
