The system time edit box probably needs to be a bit larger if you want to let the user set the date, too.
Btw. I'd go with YYYY-MM-DD hh:mm:ss, or just provide one pull-down menu per digit group.
I'd say that non-square pixels is also a hardware defect, and not necessarily what the developers were looking at when programming the game on their computer screens. For example, the morphing ball in Super Metroid is 16x16 pixels large, making it exactly spherical if displayed with square pixels. If the pixels are stretched to give the screen a 4:3 aspect ratio, it turns into an ellipsoid.
It's not a hardware defect, it's just a property of the system. Btw. developers were working on various systems:
- PC (Blizzard's / Factor 5's custom solutions)
- Amiga (which has lots of non-square pixel resolutions)
- SF-BOX (with PC-9801 / Sony workstation)
- SNES Emulator SE (picture)
- IS-Debugger
- etc.
The NTSC standard doesn't even have a concept of pixels, it only describes lines. The TV simply sweeps horizontally over the screen and whatever signal is on the input ends up on the screen. Since this is all analog, you can have 512 equal-sized dots per line - or 511, or even 457 (a prime number). The number of distinct pixels depends on how often the input is changed per line.
Developers/artists were looking at both their screens and the TV, and it's hard to miss the non-square "pixels" on TV for large objects. For small objects like the morphing ball it's more important to use all the pixels available in that small space.
Raw emulator output is not very useful for players - you only really need it if you are debugging the emulator or related software (like savestate tools), hack ROMs, or want to do things like sprite sheets.
(Technically the raw output doesn't even include things like display width or height, it's just a really long list of color values. If emulators would simply just render each value to a pixel, games like Secret of Mana would appear like this. NES / Vectrex games can't be displayed directly at all, because they're not using RGB color channels / pixels.)
The next step is aspect ratio correction. Games on a TV are stretched to a 4:3 ratio (unless you have a widescreen one) and games expect that. On a PC you'd need a 1792x1344 display for SNES games (512x448) to avoid any kind of interpolation or uneven rows/columns. So there's the usual choice from bilinear to spline interpolation where you end up somewhere on the blurry <-> haloing/ringing scale.
CRT filters are a step up because they add accuracy and can look better. Games like Jurassic Park and Kirby's Dreamland 3 need some sort of filter to render their graphics correctly. Some systems like the NES look off without NTSC and/or CRT emulation - NES "palettes" can never be 100% accurate. And finally, the CRT emulation adds some "texture" to the pixels that makes them look much more interesting, imo.
http://forum.doom9.org/showthread.php?p=1683051
[QUOTE=cretindesalpes;1683051]Download: crt_display v1.0
This function emulates a CRT display using aperture grille (Trinitron) or Cromaclear technologies. It is slow but gives interesting results. Could be nice to chain after a NTSC defect emulator like dotcrawlplus. It implements various features like:
Works at any (non-integer) upscaling factor
Various way of adjusting the scanline thickness and beam shape
Low-pass filtering of the input signal
Specific gamma target
Beam glow
Optional colored phosphor effect and shadow mask
Automatic contrast adjustment
Halation
Very large upscale is possible, showing the grid of phosphors.
Requirements: Dither 1.26.0 or above and its dependencies, Avisynth 2.6, RGB colorspace.
Detailed instructions in the .avsi file. Prototype:
Examples of real NTSC footage with aperture grille (left) and cromaclear shadow mask (right):
ar = 10.0 / 11.0
crt_display (2*ar, 2, ppp=1*ar, blurh=2.0) # Left
crt_display (2.5*ar, 2.5, ppp=1.25*ar, maskpp=1.25, cromaclear=1.0, voff=0.25) # right
It works very well for upscaling old-school videogame captures:
Sources, point-resized:
I don’t know at which gamma these pictures should be viewed so I kept them untouched like if they were in standard sRGB.
Cromaclear display type:
More screenshots here. Default settings are generally OK, but tweaking the parameters can improve the results a lot.
My 15 kHz CRT is gone for a long time and I only have half-decent monitor photos for reference, so advices based on real CRTs are welcome to improve the emulation.[/QUOTE]
My opinion? Remove the menu, use buttons. Navigating a menu quickly becomes an exercise in frustration, especially ones with many levels and toggles. "Options|Input|Enable Input/Hotkeys When|..." are probably the worst offenders here. The only positive thing about menus is that they're easy to program.
"File" can be converted to 5 buttons ("Load State" and "Save State" in drop-down style for the file lists), "Options" and "Debug" can open non-modal windows, "Tools|Slow Motion" can be a dropdown text field (like the Zoom Level control in Acrobat Reader and other document viewers).
If you keep the menu, at least don't Capitalize every single word.
It's just a bug in the game. The values read from Open Bus would appear to be semi-random to a programmer who doesn't know how the CPU works internally, but we do know that and the results are always the same (which is why games like Speedy Gonzales are still working on the bsnes core and on real hardware).
It's like deleting a file and immediately accessing that part of the hard drive again, without the system doing anything else inbetween. Technically it's undefined (you're not supposed to read "free" space), but it'll always work in practice.
If this is relying on Open Bus, I'd really need to see this get console verified before I make any votes on this run.
What exactly is Open Bus? I still don't get what's happening here.
Open bus is range of address space where no device (Work RAM, Cartridge ROM, CPU registers, PPU, Sound processor, etc...) responds.
As consequence, if CPU tries to read from that address, no device will place anything on data bus (causing the read to give what happened to be on data bus before).
What is on the the data bus changes in response to reads from non-open bus (since responding device will write to data bus) and writes to any address (even if open bus, since CPU will write to data bus).
There is possiblity that if data bus is not used for anything for a while, various parasitic conductances will drain the parasitic capacitances, causing the value that CPU would read to change.
Right. Or in other words...
The SNES CPU has this pinout assignment. There are 24 address lines (CA0-CA23), 8 data lines (CD0-CD7) and several other lines (clock, CPURD, CPUWR etc).
So the system has a 24-bit address bus (the address space is 2^24 = 16777216) and an 8-bit data bus (it can read/write one byte at a time). As far as the CPU is concerned, all these addresses are mapped to ROM or RAM chip(s), but the SNES has additional logic that maps other devices into the address space - for example 0x??4016 and 0x??4017 (the upper 8 bits don't matter) are connected to the SNES joypad ports.
AFAIK the state of the address and data pins is backed transparently by a simple flip-flop per pin. The group of bits for the address bus is called the memory address register (MAR), and for the data bus it's called the memory data register (MDR). Reading a value from "memory" goes like this: the CPU sets the MAR to the address it wants to read from, and activates the CPURD line. In the next system clock cycle, the device connected to that address changes the state of the data bus lines which changes the MDR value. The CPU can then access the returned data at any time.
Since the program code is also stored in the address space, when a read instruction is executed the MDR may contain the last byte of the instruction (e.g. part of the opcode arguments such as an indirect base address). When the device doesn't change a data bus line then that bit will be basically undefined (its value depends on how that address was read).
Then even 320kbits/s MP3 would be better (by being smaller) than raw WAV, because YT re-encodes it anyway and at that level you're not going to hear a difference.
Of course you might not mind the audio stream's size being ~5 times larger... I just think it's a waste of uploading time.
Yeah, glitching at this level isn't going to be stable on real hardware, no matter how accurate our emulation gets.
[*] I have two different candidates for the correct behaviour:
- Do it like bsnes v094 does: Return MDR, updated on write.
- Do it like bsnes does for S-CPU (S-CPU and SA1 share execution core): Return MDR, update on read and write.
Interesting that the G-Next bugfix ended up affecting something else.
But yeah, prior to the fix, there was no function return statement for open bus regions in the SA-1. So it'd be up to the platform/compiler what was in EAX for Intel/AMD systems. Definitely not hardware accurate.
The second behavior is correct. I just neglected to add the MDR assignment to SA1::op_read as well. I'll get that into v095.
It would be nice if they would post here. We may have missed this bugfix if you hadn't linked to it in a thread I rarely read. That said, they are refreshingly polite and cordial about it. I'd be pissed off if I went to all that trouble making a TAS and this happened.
Each line, the game feeds Mode 7 matrix values to the PPU via the HDMA channels.
Channel 1 sets matrix parameter A
Channel 2 sets matrix parameter B
Channel 3 sets matrix parameter C
Channel 4 sets matrix parameter D
Channel 5 sets BGMODE: Mode 0 on line 0, Mode 7 on line 24, Mode 0 on line 112, Mode 7 on line 115
Channel 6 sets Main Screen layers (turns off layers 2-4 during the Mode 7 lines; useless because they wouldn't get rendered anyway)
Channel 7 sets window coordinates (probably for the transparent digits)
I'm not sure you'll need that though when you can get the camera position...
I don’t know at which gamma these pictures should be viewed so I kept them untouched like if they were in standard sRGB.
Cromaclear display type:
