Яндекс

Thursday, July 5, 2018

1998 FIFA World Cup

Hello,

As you know, right now 2018 FIFA World Cup is held in Russia. 20 years ago 1998 FIFA World Cup was hosted in France. Of course, such event was reflected in numerous video games on all actual platforms of that time, including N64.
One of such games is International Superstar Soccer 98. Unfortunately, GLideN64 had problems  with emulation of PAL version of the game. Why PAL version is important? Because PAL version has World Cup France 98 national teams squads updated and licensed, while the NTSC version only has the kits, but not the names of the players. So, if you want to refresh in mind who participated in the World Cup 20 years ago, you will definitely like to run PAL version of ISS 98. The issue with emulation of this game is already fixed, so you may run it with latest WIP build.

The problem with this game is quite interesting. It is related to Video Interface emulation.
Video Interface (VI) takes frame buffer rendered by RDP and maps it to TV screen. VI can skip some lines of the buffer from top and bottom, but in almost all cases it reads each line in the buffer from the beginning. I knew only one exception: Bottom of the 9th, baseball game. Title screen has vertical black bars from left and right on TV screen. Rendered frame buffer has only one wide vertical black bar on the right. That is image was centered on screen by VI. To do that, VI set read address that it points to the middle of the black area on the right. VI reads data from frame buffer line by line using specified buffer width. Since VI set start of the line at the middle of black area, it first reads half of black part of the line and then part of the next line until the middle of its black area, see the screen shot:

That way output will have black boarders from left and from right. OpenGL does not read data from buffer line by line. Thus, I added special code to emulate that effect:

PAL version of ISS 98 is another game, which starts to read lines from frame buffer with some offset. This time I don't understand the purpose of it. Look: VI starts to read buffer's line with some offset from the left and stops to read it before the line ended:
Thus, only part of the line appears on TV screen. I don't know, why developers made it that way. My code for Bottom of the 9th detected that VI reads frame buffer with offset and shifted image out of screen. I modified the code to take this situation into account too. Since VI reads only part of each line in the frame buffer, the resulted image on screen becomes cut from left and right:

Saturday, May 26, 2018

HLE implementation of microcodes for "Indiana Jones" and "Battle for Naboo" completed.

Hello!

The long-awaited implementation of Factor5 microcodes for "Indiana Jones & the Infernal Machine" and "Star Wars Episode I - Battle for Naboo" completed. It was a long road. We started that work last December and finished it only now. It was incredibly hard task. Until December the hardest task we completed was our previous work, microcode for Star Wars - Rogue Squadron. We worked several months on Rogue Squadron. It is very large and very complex microcode. Resulted source code has circa 1300 lines, much larger than implementation of any other microcode. Microcodes for Indiana and Naboo are almost as large as the one for Rogue Squadron, and much more harder to decipher. Factor5 programmers really pushed RSP chip to its limits. We spent six months on decoding and implementation. The microcode has very tangled code flow. Debugging was very long and painful process. Many times I wished to stop that work and never return to it. It was huge relief when we finally squashed the last bug and completed reverse engineering stage. The result is circa 2300 (sic!) lines of source code after all cleanups. Hardest part of work - microcode deciphering - done entirely by olivieryuyu. He wrote tons of excel sheets with explanations how things work. I wrote the code.

I recommend to read interviews with Factor5 developers on IGN for technical details: Bringing Indy to N64 and Battling the Naboo. Cite: "Our new microcode allows almost unlimited real-time lights and a much higher polygon count than the original". It is true. Real time lighting system is amazing. Particles system, which can output thousands particles per frame is very impressive. Microcode for Indiana is true masterpiece. Microcode for Naboo is an extension of the one for Indiana. It extends original microcode with command for explosions (very similar to the one for Rogue Squadron) and with commands for terrain polygons. Landscape generation code has almost nothing in common with landscape code in Rogue Squadron. The result is very impressive. Open air levels have very large draw distance with no need to hide horizon in fog.

I recorded few videos during that long work. You may watch them to see how the project progressed:





Links to test builds can be found on GitHub: https://github.com/gonetz/GLideN64/issues/1259

To help the project:

Sunday, May 6, 2018

Overscan

I have many request from users to "remove these darn annoying black boarders". They refer to black boarder around image, which many N64 games add to compensate overscan. Games for old consoles designed to have black boarders and since GLideN64 does its best to produce as accurate picture as possible, it shows black boarders too.
Black boarders, which can be cropped.
However, GLideN64 does its best to be user-friendly. Thus, Public Release 2.0 introduced Crop feature designed to crop black boarders from the image. Crop efficiently eliminates black boarders, presented in rendered frame buffer.
Crop. Black line at the bottom added by VI.
 However, it does not fix the problem entirely. Many games render image without boarders, but when Video Interface put that image on TV screen, it can do it with offsets from edges of visible area, thus adding black boarders to output by itself. Crop feature can't do anything with such cases. Besides, Video Interface almost always skips one-two scan-lines on top and bottom. These black lines are visible even with Crop enabled. Especially sad story is with PAL games. NTSC standard uses 480 scan-lines. Games programmed to look crisp on TV with 480 scan-lines. PAL uses 576 scan-lines. When NTSC game ported to PAL, it becomes the problem. Game needs larger rendering buffer to utilize 576 scan-lines without loss in quality. These requires massive changes in program code with debugging and testing. Thus, most often porting done in lazy way: ignore extra scan-lines and just center our 640x480 image on PAL TV screen with Video Interface. Result is very large vertical boarders on top and bottom, which GLideN64 of course emulated:
PAL version. Crop can't do anything with black horizontal boarders.
I understand that users are not happy about it, but accuracy first.

I was remembering about that not-critical but annoying problem. Crop of rendered buffer was quite easy and fast to implement. Removal of black boarders added by VI is harder. Recently I got one spare day and decided to make ultimate solution for that problem. The idea has direct analogue in real life. If whole TV picture looks like this:


TV could be tuned to enlarge the picture and move its edges out of visible area:


I made Overscan feature, which, when enabled, redirects output of Video Interface from screen to auxiliary render buffer. Part of that buffer then mapped to screen. In fact, it is Crop, but moved to the final stage of image processing. Offsets from each edge are user defined:
As for Crop, Overscan defines offsets in native resolution. Thus, the same settings work for any user resolution. Our PAL example looks like this with Overscan enabled:

Of course, Overscan is compatible with widescreen hack:
PAL game in FullHD + Overscan
Offsets also can be negative. In that case image becomes shrunk instead of enlarged and we get even bigger black boarders:

Why do that? I don't know. Just an option.

The only problem I see with Overscan feature is that I don't know how to make it automatically pick necessary offsets. User have to do it manually. Overscan settings can be added to ini file with custom game settings. That is, user may pick offsets for a game, save them as custom game settings and never return to that procedure. Custom settings use internal rom name, which is usually the same for PAL and NTSC versions. Since PAL and NTSC versions usually need different Overscan offsets, Overscan has two set of settings.

File with custom settings has plain text format. It can be modified in any text editor and until now it was the only way to update the custom settings file. I implemented save of current settings to custom ini from GUI to simplify that task for end users. If option "Use per-game settings" is enabled, GUI will suggest user to save current settings to custom section. Settings with non-default values will be added to custom section. Run a game, enable Overscan, pick offsets and when everything is Ok save settings to custom ini.

Since image is cropped and then mapped to screen, I recommend to use "Multiple of native resolution" option and set large multiple to get image in high resolution. That way you will avoid quality loss with Overscan. And the last note: proportions of rendered objects are changed when Overscan is used.

To help the project:

Friday, January 5, 2018

"Indiana Jones and the Infernal Machine" crowdfunding campaign

Hello,

After successful completion of crowdfunding campaign for "Star Wars - Rogue Squadron" people asked us: what about "Indiana Jones" and "Battle for Naboo"? The answer was: these games are in our to-do list. These games also developed by Factor 5, two years after Rogue Squadron. Developers created unique and very complex microcodes, which push N64 hardware to its limits. Decoding and implementation of these microcodes pushes our skills to limits. At the end of November oliveryuyu and me decided to start that work while oliveryuyu's decoding skills are not faded. We worked hard and implemented part of microcode for Indi to the end of last year. This part contains code necessary to run Indiana's intro and menus. It is a proof that we can do that task. However the task is really hard, so we ask for your support again. We started new crowdfunding campaign in Idiegogo:

https://igg.me/at/indihle

We want make Indi to run fast and look better than it currently looks in LLE mode. We will do our best to implement microcode for "Battle for Naboo" as well.

I have a request for GLideN64 users: I don't have accounts in social networks. Please help me to spread information about this campaign.


Update: The result after three weeks of the campaign: 14 backers, 60% of the goal. I did not expect that this long expecting work will get so low support. This campaign has fixed goal, which means "all or nothing". If campaign will fail, we will get nothing. It is kinda discouraging.
Anyway, yesterday we got another prove that the task can be completed. Here WIP screen shots from in-game:


Update 2: The campaign funded. Big thanks to all backers! Track the progress on campaign page:
https://www.indiegogo.com/projects/indiana-j-infernal-machine-high-level-emulation#/updates/all