Posts for JosJuice


1 2
6 7 8
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
This issue has been reported before, but I don't know why it happens. https://bugs.dolphin-emu.org/issues/9016 (By the way, setting the frame limit to Auto is better than 60 fps, because it will pick the right frame rate automatically. There's no difference between them for NTSC SSBM, though.)
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
jlun2 wrote:
Which I presume means use that latest SVN instead of v5 for now.
Yes, though the correct way to say it is "use the latest development build instead of the 5.0 release candidates". Dolphin changed from SVN to git a while ago, and there is no 5.0 release yet.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
got4n wrote:
Dolphin wiki doesn't mentions at all zombie not functionnal, and moreover how has the guy made TAS? I'm probably wrong but eh xD
Dolphin 4.0-6512 (in June 2015, which is after the TAS was made) removed the ability for TASes and netplay to use files on the Wii NAND but did not affect regular usage. I don't know for sure if that's the reason the game doesn't work, but it seems likely.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
grassini wrote:
player keeps crashing,can't watch the video,anybody else got this problem?
If you'd rather watch it on YouTube, it's also available there: Link to video
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Holding the frame advance key is now working again, starting with 4.0-8061. The bug that makes Dolphin unpause sometimes when using frame advance is not fixed, though.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Maybe the code is for Classic Controllers, not Wiimotes?
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
While looking a bit closer at the encode that was posted here, I noticed that you made a new line after typing the A at the end of the program. Is there any reason for that? Also, for the submission text... I'm pretty sure there is no .x8p format. The TI-83 uses .83p and the TI-83 Plus uses .8xp. If you want to avoid the "serious mojibake", use these characters: → instead of ü, ᴇ2 instead of û2, and ʟA instead of áA. You are also lacking a space in Output(10fPart(B),int(B)," , and there's something weird with the parentheses, but maybe that's just how the markup works? The reason that the game ends when the snake is 100 tiles long is that the outermost loop is a For loop that runs until A=ᴇ2 (where ᴇ2 means 10^2, i.e. 100). It's a bit unexpected to have a For loop there, but it does work as a method of not getting an error when the snake hits 100. The TI-83 can only keep 99 elements in lists IIRC, unlike newer calculators in the series, so trying to execute A→dim(ʟA with A=100 would lead to the game exiting with ERR:INVALID DIM.
BrunoVisnadi wrote:
There is some luck manipulation,
The run contains no luck manipulation at all, and the only possible luck manipulation is as easy to do in real time as just launching the program.
BrunoVisnadi wrote:
input pressed for less than 5 frames, and as the submission text says, you have to press inputs in advance.
You have to press during ~80 ms after the end of the snake is erased (which happens ~80 ms after the front of the snake is drawn) or in advance. It's essentially a long input window (same length as the period of time between two frames) combined with input delay. Unfortunately, the input delay is very long because the game runs the getKey command right after the Output commands. If it hadn't been for the command that draws food, we wouldn't even have the 8 ms window after the snake is erased.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
dwangoAC wrote:
This would give me a different initial pattern but would provide no other benefit, I'm afraid.
Indeed. Maybe it would save a little bit of time from having a better sequence, but it wouldn't let you do any major RNG manipulation.
dwangoAC wrote:
A human would have to make literally hundreds of 5-frame window button presses throughout the run *or* be able to see into the future.
Predicting the future isn't especially hard since the only thing that will happen in the future is the snake moving according to your previous input. Well, the game might generate new food too, but you don't need to know about that if you already have a planned route. I don't expect any one to actually do a real-time run like this one, so there is still some difference between TAS and non-TAS, but this combined with the game choice makes me think that it isn't a good fit for the vault.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
BrunoVisnadi wrote:
Well, it obviously does differ from a human play. Such route plan wouldn't be possible without tools. So, according to the vault rules, why isn't it vaultable?
Both the run and the game are judged if a homebrew game is used. The only official game for TI calculators as far as I know is the puzzle pack that includes Block Dude. And no, I wouldn't say that it's obviously different from human play. The route is hard to figure out in real-time, but if you make a route in advance, you might be able to play as well as this TAS if you have a lot of patience.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
thatguy wrote:
It's a real shame that the snake can't be made to move faster. Is this a limit imposed by the calculator's processing power?
It's because of the calculator's limited processing power combined with the inefficiency of TI-BASIC. An Snake game written in assembly could be much faster.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Since the game gets random numbers using rand/randInt, you should be able to manipulate the RNG by running 0→rand on the homescreen. 0 will produce the default seed, and any other number will produce some other seed. Have you tried it? And is tampering with the RNG like this allowed? Normally it would be some more random value if you had used the calculator for other things between turning it on and starting the game. In my opinion, this game and TI-BASIC games in general are too slow to make an entertaining TAS. TASing assembly games (or Axe games, for when there's TI-83 Plus support) would be better.
BrunoVisnadi wrote:
So it is impossible to get a 'ROM' of this game?
You can get the game as a program file, and you can send it over the link port instead of typing it in manually. However, you can only send it to RAM, because this calculator series didn't get flash memory until the TI-83 Plus. That means that if you want to start the movie from a point where the game already is installed, you can't start from power-on. (I'm talking about how it works on real hardware - I'm not familiar with BizHawk's TI-83 support.)
solarplex wrote:
What?! No Sound!? Ugh.. Yes Vote.
Such is the world of calculators :) Only a tiny number of games for the TI-83 Plus/TI-84 Plus support sound, and I don't know if there are any at all for the TI-83. The main reason is that the only way of producing sounds is bitbanging the link port, which uses a lot of precious CPU time. Doing it in TI-BASIC is completely out of the question. Another reason is that those who make games can be reluctant to add features that most people won't be able to use. People generally don't keep 2.5 mm port headphones around so that they can use them for their calculator...
Riddim wrote:
there was a "boxman" puzzle game i used to play on my ti-83 that i would love to see a TAS.
I assume you mean Block Dude for the TI-83 Plus? The TI-83 and TI-83 Plus are two completely different models, though they do have a lot of similarities since they're in the same series. Games written in TI-BASIC (like this Snake game) are usually cross-compatible, but games that use native code aren't cross-compatible, though they are reasonable to port if you have access to the source code.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
oxysoft wrote:
About the DTM I shared earlier, the version I was using was Dolphin-r7161.
I assume you mean 4.0-7161? The r numbering scheme hasn't been used for a few years, and the new versions shouldn't be confused with old versions that end in the same number. Also, yes - there are definitely things that Dolphin lacks from a TASing perspective. Progress on TAS-related things is unfortunately slow, but I appreciate you and others writing about what's bad with Dolphin so that we're aware that there's work to be done.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
There's a preliminary fix available, but it isn't available in the official Dolphin versions yet.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
It hasn't been posted, but it isn't forgotten either. We need to wait until more of the details are known.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
AR codes change the game's code, so it makes sense that they cause desyncs. Dolphin's widescreen hack should be sync compatible unless the game does something weird, but the result will of course not be as good.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Dimon12321 wrote:
And what are the main changes comparing to 4.0?
In general, there have been many accuracy and performance improvements. To make some of these improvements possible, support for old things like Direct3D 9 and 32-bit CPUs has been dropped. A few examples of accuracy improvements:
    * The Star Wars: Rouge Squadron games are now working, with only a small number of issues left * Pokémon Snap is now working (yes, unlike actual N64 emulators...) * The Paper Mario: TTYD graphics glitches with Punies and with water reflections have been fixed, although the graphical effects in this game will no longer work with certain old graphics cards * Many other graphics fixes, like the ones seen in the screenshots here: https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/
For non-TASing:
    * Wii games now work over netplay, and there have been other netplay improvements too, but Wii Remotes usually make everything desync * Native support for GC controller adapters * Improved support for GBA communication (not compatible with netplay or TAS at the moment) * GameCube save data can optionally be stored in memory card folders instead of memory card files * 3D stereoscopy
...and a bunch of stuff that isn't significant enough to include for a summary like this. I've probably forgotten things too. There'll be a better list when the 5.0 release happens. For TASing:
    * A/V sync for dumping built-in to replace the A/V sync hack * TAS input for more controllers: Nunchuk, Classic Controller (Wii Remote too? I don't know things that far back) * Replays in games like SSBB, Mario Kart Wii and F-Zero GX are now sync-compatible with consoles * The loading times are now more similar to ones on real consoles. There are still improvements to be made, especially for Wii discs, but they've become much better than they were in 4.0. Most people don't care about this, but it's been heavily requested by people interested in Metroid Prime TASing, so I figured I'd include it in this list.
Like others in this topic have said, some new problems have unfortunately been introduced. Frame advance not working when held, frame advance sometimes unpausing, and memory usage going up when loading savestates are all listed as blocking issues for 5.0 and should thus hopefully be fixed before the final release. There are also some crash fixes for TAS input that are in the development builds but not the release candidates yet that probably can make their way in.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Captain Forehead wrote:
Are you suggesting that I have a broken driver?
It's possible that there's something wrong with the driver, yes. Intel's drivers have problems sometimes, but the luckily the Windows drivers don't have as many problems with Dolphin as the OS X ones.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
I suggest updating the drivers for your Intel GPU. There was talk once about making Dolphin automatically delete the old shaders if you had one of the affected GPUs, but I think the conclusion was that it only was an issue with certain broken drivers.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
That's your CPU, not your GPU. Anyway, you can try to go to C:\Users\<username>\Documents\Dolphin Emulator and delete the ShaderCache folder. It gets created every time you run a game, and some Intel GPUs apparently have an issue with loading shaders from there.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Which Dolphin version and operating system are you using? Are you using an Intel GPU?
Post subject: Re: Frame advance hangs/unpauses?
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
yoshifan wrote:
I was looking through the issue tracker but couldn't find this. Could someone provide a link?
https://code.google.com/p/dolphin-emu/issues/detail?id=8718
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
ALAKTORN wrote:
What does this even mean? Where do I right click? Dolphin’s window is not showing the game for me, even when I browse for the folder with the game in it.
Go to Config > Paths and add the folder that contains the game. The game should then show up in Dolphin's main window, ready to be right-clicked. If it doesn't show up, make sure that everything is checked in Show Platforms and Show Regions in the View menu.
ALAKTORN wrote:
My game file is called ck-psoe12.gcm which I have no idea what .gcm even is.
It's the same thing as ISO, just with a different extension.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Wait, so Dolphin runs as fast as in the video for you? It should run at the right speed if framelimit is set to Auto and you aren't holding the toggle framelimit hotkey.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Soig wrote:
ALAKTORN wrote:
Well the Wii U is not a Wii. Were you using Virtual Console or the Wii disc on Wii U?
Use homebrew channel to run .wbfs on sd card. I transformed nsmbw.iso to .wbfs.
Using a backup loader instead of a real disc will give you very different results when measuring the time it takes to do things. The newest versions of Dolphin try to emulate the speed of a real disc. The emulation is nowhere near perfect, but it's generally more accurate than backup loaders.
JosJuice
She/They
Editor, Emulator Coder, Experienced Forum User
Joined: 7/3/2010
Posts: 193
Location: Sweden
Anty-Lemon wrote:
Malleoz wrote:
Glitch stuff
If you redo the run, could you please start it with the latest dev version instead of the latest stable? It'd help a lot in terms of encoding
Also, if you aren't already, please use a proper 1.35 GiB disc image instead of those trimmed ones that can be found online. The sync is probably affected by it in the newer Dolphin versions.
1 2
6 7 8