Some Quick Relevant Updates Need Addressing...

The official forum for ZSNES documentation. Discuss future changes, mistakes, etc...
You can also join us on IRC at irc.freenode.net in #zsnes-docs.

Moderators: ZSNES Mods, ZSNES Doc Team

Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Jipcy wrote:
Nach wrote:
Deathlike2 wrote:The path AND filename must be put in for Same Game and G-Next in order for it to work.
Unless the ROMs are using the default names and are in the same directory as the child ROMs being loaded.
What are the required filenames for both the base ROMs and child ROMs, in order for this to work? I was testing it a bit and I couldn't make it work without specifying the full path and filename.
SAMEGAME.ZIP, G-NEXT.ZIP, STBIOS.ZIP, placed in the same ROM directory as the child. Load the child and presto.

I'm thinking of making it look for name.sfc, name.bin, name.zip, name.gz, name.jma if nothing is specified.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

No wonder it never worked automatically for me. It looked for the zip. I always extract the games.

Anyways, this thread needs documenting:
http://board.zsnes.com/phpBB2/viewtopic.php?t=8930
It needs a FAQ question, and an entry for the files ZSNES creates for the cheat search.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Code: Select all

Select Format: DEC (Decimal, 0 .. 9), HEX (Hexadecimal, 0 .. F). Most of the time, it's recommended that you use decimal, although there are some cases that the values in memory are sometimes stored as hex.
This makes no sense at all.
Data is data, whether you read it as dec or hex is up to the user and a matter of preference and interpretation of said data.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
whicker
Trooper
Posts: 479
Joined: Sat Nov 27, 2004 4:33 am

Post by whicker »

Nach wrote:

Code: Select all

Select Format: DEC (Decimal, 0 .. 9), HEX (Hexadecimal, 0 .. F). Most of the time, it's recommended that you use decimal, although there are some cases that the values in memory are sometimes stored as hex.
This makes no sense at all.
Data is data, whether you read it as dec or hex is up to the user and a matter of preference and interpretation of said data.
Select Format: DEC (Decimal, 0 .. 9), HEX (Hexadecimal, 0 .. F). Most of the time, it's recommended that you use decimal, although there are some cases that the values in memory are sometimes stored as binary coded decimal. example: "34 lives" could be stored in a byte as 34h, which if you were searching for it in the decimal mode, would actually have a value of 52.

It made sense back then, it makes sense now. However, I do agree that a little more explanation is appropriate.
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

whicker wrote:
Nach wrote:

Code: Select all

Select Format: DEC (Decimal, 0 .. 9), HEX (Hexadecimal, 0 .. F). Most of the time, it's recommended that you use decimal, although there are some cases that the values in memory are sometimes stored as hex.
This makes no sense at all.
Data is data, whether you read it as dec or hex is up to the user and a matter of preference and interpretation of said data.
Select Format: DEC (Decimal, 0 .. 9), HEX (Hexadecimal, 0 .. F). Most of the time, it's recommended that you use decimal, although there are some cases that the values in memory are sometimes stored as binary coded decimal. example: "34 lives" could be stored in a byte as 34h, which if you were searching for it in the decimal mode, would actually have a value of 52.

It made sense back then, it makes sense now. However, I do agree that a little more explanation is appropriate.
Ah, that does help a lot.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
AspiringSquire
Born to Rule... Impatiently
Posts: 265
Joined: Wed Nov 17, 2004 8:21 pm
Location: Everywhere I want to be.
Contact:

Ridiculous note about 8-bit engine being 16-bit compatible

Post by AspiringSquire »

What's available in the old graphics engine when using an 8-bit color video mode:
* Offset per tile mode (mode 2/vertical only)
* High-res 512 horizontal resolution (missing in 16x16)
* Single and dual windowing routines
* 16-bit graphics support??????????????????????????????
The note about the old graphics engine having 16-bit graphics support in 8-bit color video mode is ridiculous, and this confusion only surfaced because of poor organization in that part of the Current Progress section before it was updated somewhat recently. I'm sure it's safe to remove that line. Right, guys?
[url=http://board.zsnes.com/phpBB2/viewtopic.php?t=3298][color=brown]My [u]NES palette[/u][/color][/url] - better colors with any emulator.

"the more you know, and the more you can do... the more you are."
- [url=http://www.danielbohman.com][color=brown][u]daniel bohman[/u][/color][/url]
Jipcy
Veteran
Posts: 768
Joined: Thu Feb 03, 2005 8:18 pm
Contact:

Re: Ridiculous note about 8-bit engine being 16-bit compatib

Post by Jipcy »

AspiringSquire wrote:I'm sure it's safe to remove that line. Right, guys?
I'd rather just wait for a developer to look over the entire Current Progress section before the next release, to verify that everything is accurate.
[url=http://zsnes-docs.sf.net]Official ZSNES Docs[/url] | [url=http://zsnes-docs.sf.net/nsrt]NSRT Guide[/url] | [url=http://endoftransmission.net/phpBB3/viewtopic.php?t=394]Using a Wiimote w/ emulators[/url]
Jipcy
Veteran
Posts: 768
Joined: Thu Feb 03, 2005 8:18 pm
Contact:

Post by Jipcy »

Deathlike2 wrote:
whicker wrote:
Nach wrote:This makes no sense at all.
Data is data, whether you read it as dec or hex is up to the user and a matter of preference and interpretation of said data.
Select Format: DEC (Decimal, 0 .. 9), HEX (Hexadecimal, 0 .. F). Most of the time, it's recommended that you use decimal, although there are some cases that the values in memory are sometimes stored as binary coded decimal. example: "34 lives" could be stored in a byte as 34h, which if you were searching for it in the decimal mode, would actually have a value of 52.

It made sense back then, it makes sense now. However, I do agree that a little more explanation is appropriate.
Ah, that does help a lot.
So are we in agreement to change this description per whicker's suggestion?
[url=http://zsnes-docs.sf.net]Official ZSNES Docs[/url] | [url=http://zsnes-docs.sf.net/nsrt]NSRT Guide[/url] | [url=http://endoftransmission.net/phpBB3/viewtopic.php?t=394]Using a Wiimote w/ emulators[/url]
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Re: Ridiculous note about 8-bit engine being 16-bit compatib

Post by Deathlike2 »

Jipcy wrote:
AspiringSquire wrote:I'm sure it's safe to remove that line. Right, guys?
I'd rather just wait for a developer to look over the entire Current Progress section before the next release, to verify that everything is accurate.
Looks like an obvious oversight. Feel free to remove.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Jipcy wrote:
Deathlike2 wrote:
whicker wrote:
Nach wrote:This makes no sense at all.
Data is data, whether you read it as dec or hex is up to the user and a matter of preference and interpretation of said data.
Select Format: DEC (Decimal, 0 .. 9), HEX (Hexadecimal, 0 .. F). Most of the time, it's recommended that you use decimal, although there are some cases that the values in memory are sometimes stored as binary coded decimal. example: "34 lives" could be stored in a byte as 34h, which if you were searching for it in the decimal mode, would actually have a value of 52.

It made sense back then, it makes sense now. However, I do agree that a little more explanation is appropriate.
Ah, that does help a lot.
So are we in agreement to change this description per whicker's suggestion?
This looks fine.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

The Graphics Engine section doesn't look quite right...

About the old graphics engine:
13-bit color rendering needs to be made clear that it is only accessible while you are using a 16-bit mode or greater (the exception is 24-bit modes for Windows/SDL ports... I'm not sure what the deal is with the SDL port, but Windowed modes in the Windows port only support 16 or 32-bit color desktops).

Hires mode 7 is available for any 16-bit mode with a res of 512x448 or greater. The exception is DOS, where it is implemented on the 640x480x16b mode only.

I don't particularly like the "MMX compatible CPUs only" term... it could be better said as "requires MMX support".

Someone else could better comment on this though.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Ok, it's crunch time soon...

For the FAQ, I did remember some relevent questions that may need to be included:

Q: I'm not using a QWERTY keyboard, wtf is going on?
A: When the GUI was written, it wasn't exactly a consideration at the time to implement a system to handle such details. Maybe in the future it will be implemented (I probably would do it, but it is certainly not a primary goal of mine).

Q: I want to mod ZSNES to my language like what ZFont is doing for ZSNES, will I be able to mod it?
A: Probably not. The way the GUI was coded, there are inherant limitations that prevent this from occuring. Unless the GUI is redesigned (and updated for hires), it is certainly not happening. (It will get a facelift someday, but not by user demand.)

(This question may replace/help some older questions about when ZSNES will have X fixed)
Q: Why are some games really screwy? WTF did you do?
A: The core needs to be replaced to improve accuracy. This was not a concern back in the day where performance was necessary to run your favorite game better. Considering that this is not the case anymore, a new core will be added in at some point. Please do not bug us as to when it will be released. It will be available when it is done. Also, the sound core will be replaced with an open source lib (thanks to TRAC). Please do not ask when it will be done.


In any case, these questions/answers can be tweaked if needed. It should help reduce the number of queries we have on these issues.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
AspiringSquire
Born to Rule... Impatiently
Posts: 265
Joined: Wed Nov 17, 2004 8:21 pm
Location: Everywhere I want to be.
Contact:

The usefulness of SRAM Check+Save, thwarted.

Post by AspiringSquire »

GUI page wrote:SRAM Check+Save - When this option is enabled, ZSNES will write SRAM data to disk shortly after a game modifies it. With this disabled, ZSNES will write SRAM data when you exit the emulator or exit to the GUI.
You know, this (above) is the way it's supposed to work, but right now it's doing this instead:
SRAM Check+Save - Normally, ZSNES will write SRAM data to disk when you exit the emulator or exit to the GUI. When this option is enabled, ZSNES will also write SRAM data shortly after a game modifies it.
It was a feature of SRAM Check+Save to be an alternative to the standard save method, not an addition. Originally, with SRAM Check+Save enabled, you wouldn't have to worry about overwriting your game's save data when loading a savestate, as long as you didn't try to save within the game. The current system for saving thwarts what I consider to be the most useful aspect of SRAM Check+Save. Therefore, I am requesting that the normal procedure for saving (upon exiting to the GUI and when exiting ZSNES) be withheld when SRAM Check+Save is enabled. I think this would also be more like the way the SNES does it.
[url=http://board.zsnes.com/phpBB2/viewtopic.php?t=3298][color=brown]My [u]NES palette[/u][/color][/url] - better colors with any emulator.

"the more you know, and the more you can do... the more you are."
- [url=http://www.danielbohman.com][color=brown][u]daniel bohman[/u][/color][/url]
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Post by Nach »

Uncheck load state with SRAM and don't worry about it.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
AspiringSquire
Born to Rule... Impatiently
Posts: 265
Joined: Wed Nov 17, 2004 8:21 pm
Location: Everywhere I want to be.
Contact:

SRAM Check+Save to allow unhampered viewing of save contents

Post by AspiringSquire »

With both "Load Save State with SRAM" and "SRAM Check+Save" (as it used to be) enabled, you would be able to view the save data contained in a save state (via menus in-game) AND not have to worry about your current SRAM getting overwritten. There is no good substitute for this handy capability; the alternatives would involve making backups of your SRAM (and copying it back afterwards) for every time you want to check a state's save contents. For some RPGs in particular, I like to keep saves at several points in the game (so I can return to various events without playing through several hours over again), and this original function of SRAM Check+Save made it nice and easy. Could you please give SRAM Check+Save exclusive saving privileges when it is enabled (i.e. by not saving SRAM at the GUI, nor on exit)?
[url=http://board.zsnes.com/phpBB2/viewtopic.php?t=3298][color=brown]My [u]NES palette[/u][/color][/url] - better colors with any emulator.

"the more you know, and the more you can do... the more you are."
- [url=http://www.danielbohman.com][color=brown][u]daniel bohman[/u][/color][/url]
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Re: SRAM Check+Save to allow unhampered viewing of save cont

Post by Nach »

AspiringSquire wrote:With both "Load Save State with SRAM" and "SRAM Check+Save" (as it used to be) enabled
Never existed before. We just added SRAM to ZSTs recently.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
AspiringSquire
Born to Rule... Impatiently
Posts: 265
Joined: Wed Nov 17, 2004 8:21 pm
Location: Everywhere I want to be.
Contact:

This SRAM Check+Save implementation is worth considering

Post by AspiringSquire »

Nach wrote:
AspiringSquire wrote:With both "Load Save State with SRAM" and "SRAM Check+Save" (as it used to be) enabled
Never existed before. We just added SRAM to ZSTs recently.
Okay... I know there was no option "Load Save State with SRAM" before, but I have (in the past) been able to load some states with SRAM data included; it may just be because some games also keep track of the save data in regular memory. "As it used to be" was only referring to SRAM Check+Save, not the other option.

The point remains, that if SRAM Check+Save operated as a complete replacement of the usual (saving at GUI and on exit), it would allow users to view the SRAM data in a state without overwriting their most recent saves. I think this implementation should be worth some consideration.
[url=http://board.zsnes.com/phpBB2/viewtopic.php?t=3298][color=brown]My [u]NES palette[/u][/color][/url] - better colors with any emulator.

"the more you know, and the more you can do... the more you are."
- [url=http://www.danielbohman.com][color=brown][u]daniel bohman[/u][/color][/url]
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Re: This SRAM Check+Save implementation is worth considering

Post by Nach »

AspiringSquire wrote:
Nach wrote:
AspiringSquire wrote:With both "Load Save State with SRAM" and "SRAM Check+Save" (as it used to be) enabled
Never existed before. We just added SRAM to ZSTs recently.
Okay... I know there was no option "Load Save State with SRAM" before, but I have (in the past) been able to load some states with SRAM data included
Not possible, as I said ZSTs did not contain SRAM.
AspiringSquire wrote: it may just be because some games also keep track of the save data in regular memory.
Your perception can mean many things but not that ZSTs contained SRAM.
AspiringSquire wrote: The point remains, that if SRAM Check+Save operated as a complete replacement of the usual (saving at GUI and on exit), it would allow users to view the SRAM data in a state without overwriting their most recent saves. I think this implementation should be worth some consideration.
As I said before, uncheck load with SRAM.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

AspringSquire, I think you may be missing something here perhaps?

Both options you mention work separate from each other. I'm not sure if there was something happening in between though?
AspiringSquire wrote:
GUI page as of right now wrote:SRAM Check+Save - When this option is enabled, ZSNES will write SRAM data to disk shortly after a game modifies it. With this disabled, ZSNES will write SRAM data when you exit the emulator or exit to the GUI.
Ok, that does need revising.
what you think it should say wrote:SRAM Check+Save - Normally, ZSNES will write SRAM data to disk when you exit the emulator or exit to the GUI. When this option is enabled, ZSNES will also write SRAM data shortly after a game modifies it.
That sounds about what it should say. The original premise is that if ZSNES crashes, SRAM is not saved and people get pissy/disappointed at the emu. This helps people solve said headache/heartache. However, I think you are missing the key point. When ZSNES quits successfully/normally, currently working SRAM is ALWAYS saved to disk.
With both "Load Save State with SRAM" and "SRAM Check+Save" (as it used to be) enabled, you would be able to view the save data contained in a save state (via menus in-game) AND not have to worry about your current SRAM getting overwritten. There is no good substitute for this handy capability; the alternatives would involve making backups of your SRAM (and copying it back afterwards) for every time you want to check a state's save contents. For some RPGs in particular, I like to keep saves at several points in the game (so I can return to various events without playing through several hours over again), and this original function of SRAM Check+Save made it nice and easy. Could you please give SRAM Check+Save exclusive saving privileges when it is enabled (i.e. by not saving SRAM at the GUI, nor on exit)?
Actually, that's incorrect. Whenever Load Save State with SRAM is checked, it ALWAYS overwrites the current working SRAM with its own. When Load Save State with SRAM is unchecked, the SRAM data in the savestate is ignored (not loaded). SRAM Check+Save has no actual effect on this option either way. Though, it may simply not be a safe solution in some games like Star Ocean for instance...
The point remains, that if SRAM Check+Save operated as a complete replacement of the usual (saving at GUI and on exit), it would allow users to view the SRAM data in a state without overwriting their most recent saves. I think this implementation should be worth some consideration.
No, you certainly do not want to change the behavior of a working feature. If you wanted another option that prevents currently working SRAM being saved on exit, that would probably not be a bad idea. However, note that SRAM Check+Save ensures that the SRAM is saved when modified at any given time... so it can't actually coexist.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
AspiringSquire
Born to Rule... Impatiently
Posts: 265
Joined: Wed Nov 17, 2004 8:21 pm
Location: Everywhere I want to be.
Contact:

Further explanations of SRAM-related functions

Post by AspiringSquire »

Deathlike2 wrote:Both options you mention work separate from each other.
I'm fully aware of that. My idea is based around the behavior that I would expect to result from the two of them (with their respective behaviors) being enabled simultaneously IF saving when entering the GUI and exiting the emulator did not occur when SRAM Check+Save is enabled.
Deathlike2 wrote:When ZSNES quits successfully/normally, currently working SRAM is ALWAYS saved to disk. ... Whenever Load Save State with SRAM is checked, it ALWAYS overwrites the current working SRAM with its own.
I wasn't stating otherwise; I was speaking hypothetically about the function/feature that I would like to have. The current working SRAM gets replaced when using Load Save State with SRAM, but if the emulator doesn't save on exit or on entering the GUI (this change resulting from a new function/setting), then the actual SRAM that is on your hard drive would not be replaced unless you save within the game (when SRAM Check+Save is enabled). Since being able to save at all would then hinge on having SRAM Check+Save enabled, I thought it made sense to have SRAM Check+Save be the option to prevent working SRAM from being saved on exit.
Deathlike2 wrote:If you wanted another option that prevents currently working SRAM being saved on exit, that would probably not be a bad idea. However, note that SRAM Check+Save ensures that the SRAM is saved when modified at any given time... so it can't actually coexist.
Do you mean to say that SRAM Check+Save will immediately save the newly loaded current working SRAM when a state is loaded? I would expect the option to save only when SRAM data is changed within the game, by the game itself (i.e. not when loading a state); if this isn't how it is, maybe it should be...
Nach wrote:
AspiringSquire wrote:The point remains, that if SRAM Check+Save operated as a complete replacement of the usual (saving at GUI and on exit), it would allow users to view the SRAM data in a state without overwriting their most recent saves. I think this implementation should be worth some consideration.
As I said before, uncheck load with SRAM.
After writing everything else above, I realized the implication of your response here... It might result in the behavior that I remember. But I think the feature/function that I have suggested may prove to be more reliable.
[url=http://board.zsnes.com/phpBB2/viewtopic.php?t=3298][color=brown]My [u]NES palette[/u][/color][/url] - better colors with any emulator.

"the more you know, and the more you can do... the more you are."
- [url=http://www.danielbohman.com][color=brown][u]daniel bohman[/u][/color][/url]
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Re: Further explanations of SRAM-related functions

Post by Deathlike2 »

AspiringSquire wrote:
Deathlike2 wrote:If you wanted another option that prevents currently working SRAM being saved on exit, that would probably not be a bad idea. However, note that SRAM Check+Save ensures that the SRAM is saved when modified at any given time... so it can't actually coexist.
Do you mean to say that SRAM Check+Save will immediately save the newly loaded current working SRAM when a state is loaded? I would expect the option to save only when SRAM data is changed within the game, by the game itself (i.e. not when loading a state); if this isn't how it is, maybe it should be...
As soon as you load the savestate and have "Load Save State w/SRAM" checked, whatever is the SRAM will use the savestate's SRAM, regardless of whether "SRAM Check+Save" is checked.

On the other hand, regardless of whether SRAM Check+Save is enabled, ZSNES will always save the SRAM data to disk on exit.

Edit: I went looking at the code for its current behavior just to be sure.

It happens that if you have it checked, SRAM Check+Save will write the new SRAM to disk within 5 seconds in conjunction with Load Save State w/SRAM. (I will have to update the the description in the cfg file at some point).

If there was an option to disable saving SRAM, as I believe you are suggesting, thats fine. However, it will never be able to coexist with SRAM Check+Save because SRAM Check+Save will ALWAYS save SRAM to disk every 5 seconds (there's a internal timer that decides this).

I hope this clears things up.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Nach
ZSNES Developer
ZSNES Developer
Posts: 3904
Joined: Tue Jul 27, 2004 10:54 pm
Location: Solar powered park bench
Contact:

Re: Further explanations of SRAM-related functions

Post by Nach »

AspiringSquire wrote: After writing everything else above, I realized the implication of your response here... It might result in the behavior that I remember. But I think the feature/function that I have suggested may prove to be more reliable.
After reading everything you said I realize now what you want and how it might work.
However note the SRAM check features saves 300 frames after the last SRAM write.

In the situation where a guy does save game then exits in under 5 seconds, odds are his SRAM won't save.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
AspiringSquire
Born to Rule... Impatiently
Posts: 265
Joined: Wed Nov 17, 2004 8:21 pm
Location: Everywhere I want to be.
Contact:

Bugs -- subtitles, CPU usage, mouse cursor invisibility

Post by AspiringSquire »

Deathlike2 wrote:I hope this clears things up.
Yes, I believe the three of us have reached an adequate level of understanding. Thanks for your patience.

--------

According to the current description for Movie Subtitles, 34 characters can be displayed on a single line, but I have only managed to get 30 to display in my tests. It seems that the starting position for displaying subtitles is too far to the right, but I think it won't fit 34 characters even if that were changed.

On a related note, there are problems displaying non-alpanumeric characters in subtitles; they show garbled or empty characters instead. I know that commas and apostrophes don't work, and I believe there are likely several more. Is this going to be fixed?

On an unrelated note, it seems that the 100% CPU usage fix is no longer working, at least not in the GUI, but likely not otherwise either.

There's also a very irritating bug with the mouse cursor being invisible when moving away from the ZSNES window, sometimes requiring clicking both within ZSNES and outside of it before the regular desktop mouse cursor reappears.
[url=http://board.zsnes.com/phpBB2/viewtopic.php?t=3298][color=brown]My [u]NES palette[/u][/color][/url] - better colors with any emulator.

"the more you know, and the more you can do... the more you are."
- [url=http://www.danielbohman.com][color=brown][u]daniel bohman[/u][/color][/url]
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Re: Bugs -- subtitles, CPU usage, mouse cursor invisibility

Post by Deathlike2 »

AspiringSquire wrote:According to the current description for Movie Subtitles, 34 characters can be displayed on a single line, but I have only managed to get 30 to display in my tests. It seems that the starting position for displaying subtitles is too far to the right, but I think it won't fit 34 characters even if that were changed.
Nach may have a better idea on this.. that may just be the case.
On a related note, there are problems displaying non-alpanumeric characters in subtitles; they show garbled or empty characters instead. I know that commas and apostrophes don't work, and I believe there are likely several more. Is this going to be fixed?
IIRC, there is a different font system that deal with displaying text on the screen, different from the one used in the GUI. That's probably what is giving you problems.
On an unrelated note, it seems that the 100% CPU usage fix is no longer working, at least not in the GUI, but likely not otherwise either.
If you could find the WIP or revision it started from, it would be very helpful.
There's also a very irritating bug with the mouse cursor being invisible when moving away from the ZSNES window, sometimes requiring clicking both within ZSNES and outside of it before the regular desktop mouse cursor reappears.
I have absolutely no idea what causes this. As suggested earlier... try to nail the WIP or revision this behavior started from...
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Deathlike2
ZSNES Developer
ZSNES Developer
Posts: 6747
Joined: Tue Dec 28, 2004 6:47 am

Post by Deathlike2 »

Oh yes, we need the obligatory "Why does ZSNES seg fault/crash when I compile for 64-bit?"

The answer is "most of ZSNES is in ASM, and x86 32-bit ASM is not compatible with x86 64-bit ASM".
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Post Reply