Code Pre Gfx.ff Mw3
Stephanie Dejoode
I'm also running into this problem. The custom resolution dialog only allows me to enter display modes that the display already reports to the graphics chip. Anything else and I get the message about "exceeds bandwidth". The above interaction was one of the most infuriating things I've read - kevin_intel couldn't be more obtuse. Hello! If I can only use the modes reported by the display why is there a custom mode dialog? There's clearly a bug in the code that adds custom modes, or at least the wrong error is reported. It's plainly clear that the mode I am entering does not exceed the bandwidth of anything -- it uses less bandwidth than a supported (working) mode!
Generally speaking, you cannot call FF as an API in your programs, neither in C++ nor Python. But, if you mean you want to call it as an external program, it can be done in C++ with a system call. This sort of offline linking is always possible, in which you call FF executable to solve a problem and write the solution the disk (you wait for it), and then, you collect the answer in your own code.
I guess you could also used the FF exec() function to invoke your
own arbitary code and communicate throught files or pipes.
For initial testing anyway the fileio gives you debug information when things go wrong.
Another interesting fact, is that unfortunately the driver author did stop developing it, with no further explaination, and as a last gift to the community it decided to release the driver source code, but no instructions on how to compile it. No documentation, no build system, no batch file, no Visual Studio solution. If you were interested in continuing it, you would have to figure it out yourself, or enjoy its last release 0.8.1b.
Up to this point, I can actually confirm my theory of what happened around this Steam driver: either Aali got hired by Dotemu ( and this explains why the driver stopped in being developed, and is so similar ) or they did use Aali source code to sell you just another repack, using DirectX 9 APIs instead of OpenGL. Smart move :)
This is how my next seven months would have been used from improving Aali source code, to actually come up with a totally new named FFNx. A next generation driver which allows you to use DirectX 9/11/12, OpenGL and Vulkan!
To my surprise someone else already did start a fork of Aali source code, and attempted to build it via CMake. Those people are Blake Wilkey and Maxime Bacoux. Two great guys which I had the honor to work with, and which together are cooking something which will definitely revolutionize Final Fantasy VII modding scene. But until then, you will have to wait. Sorry :)
The CMake goals were now able to build the main driver code just fine, but what about the plugins? Aali used to zip its release as its main driver ff7_opengl.fgd and a plugins directory, which contained the VGMStream plugin to load OGG music files, and the FFMpeg plugin to load movies on new systems. Knowing that, in order to mimic the official Aali release, a new CMake goal was added to build also those layers.
Another thing that was missing in mimicking the release, was that files were build statically. No external DLLs were provided. In order to do the same thing under MSVC, shipped with Visual Studio 2019, we had to build the code using Microsoft`s Universal CRT.
With this set, we were now able to have at least Aali source code shipped as people were used to. Was this time to settle? No way. The driver had to be improved as various bugs were left. Down the road, the more I was improving it based on awesome people which helped me test it ( thank you LordUrQuan and unab0mb! ), commit after commit, the more I was gaining knowledge inside of the code.
Within that list, I discovered that not only Vulkan wrappers were available, but also some multi-API rendering engines were existing, which would allow me to write the code once, and run it on multiple Graphics APIs. Sweet!
I believe you have, perhaps, confused me with one of the other
responders. I see exactly the same thing that you described, that is,
viewing the page normally, I *do* see all the graphics. When I go to
print preview, I *do not* see the last block of graphics.Although I don't believe it to be related to the problem, for the
record, my setting for the preference, permissions.default.image, is 1,
as described in my previous post: allowing "all images to load,
regardless of origin." I do not use any ad blocking extensions,
software, etc. My hosts file contains nothing beyond the standard
"127.0.0.1 localhost" entry.I don't believe these to be related, as the normal view does show *all*
the images, *nothing* is being blocked. The issue is what appears in
print preview. Note: I have not tried to print the pages, as, yet
again, I'm out of ink. I'm going to have to teach my son how to print
just the information he wants, rather than entire web pages, in full
color. :-(With my print preview Scale setting to 100%, it shows a page count of 5.I did try playing with the scale setting, as, in the past, there have
been problems with pages rendering properly for printing, depending on
the scale setting. I did not find any difference in this case, however.One thing that I did note, is that they are using separate CSS
statements for printing. I'm not an expert at it, but I'm wondering if
they have done, or not done, something with the CSS that is effecting
that last block of images.I tried looking at the source & comparing the code for the other block
of images with the block that does not print, but nothing jumped out at
me immediately. As others have pointed out, there are numerous
validation errors on this page.Hmm, ok, I spent some more time looking at this & researching. I'm
wondering if it has to do with their use of the tags.According to _tbody.asp :"Definition and UsageDefines a table body.The thead, tfoot and tbody elements enable you to group rows in a table.
When you create a table, you might want to have a header row, some rows
with data, and a row with totals at bottom. This division enables
browsers to support scrolling of table bodies independently of the table
header and footer. When long tables are printed, the table header and
footer information may be repeated on each page that contains table data.Note: If you use the thead, tfoot and tbody elements, you must use every
element. They should appear in this order: , and ,
so that browsers can render the foot before receiving all the data. You
must use these tags within the table element.Note: The , and elements are seldom used, because
of bad browser support. Expect this to change in future versions of XHTML."Searching the source for the page for the page in question reveals
numerous uses of the tag, however there are *no* or
tags at all, thus violating the standard.Since the page coder did not use the proper implementation of them, all
bets are off when it comes to printing with FF, as the code does not
comply with the standard. From the quote above, "If you use the thead,
tfoot and tbody elements, you must use every element."Of course, I could be completely wrong about this, I'm not an HTML code
guru (yet), although the standard seems pretty clear about this issue.IE has, unfortunately, allowed the propagation of an uncountable number
poorly coded sites that "magically" appear just fine in IE. As we well
know, IE will attempt to "interpret" what the code should mean. FF
strives to be strictly standards compliant. Where a page can get away
with poor code in IE, the same may not (probably not!) render correctly
in FF.Having said all that, there are issues with printing in FF. It is an
area where FF still needs work. I have noticed, generally, that I
encounter far fewer problems on standards-compliant sites, though.If you go to the main page of that site: , you
will see this statement under Site Information:"This system is compatible with Internet Explorer (Ver. 5-6) and
Netscape Communicator (Ver. 8)"My suggestion, at this point, is to notify the webmaster of the problem
& suggest that they comply with the standards. You might point out to
them that, according to most press accounts, FF continues to gain in
popularity & it would make sense to iron out the problems. In a polite
way, of course. :-)Another option would be to "Report Broken Website". On the menu bar,
choose Help >> Report Broken Web Site.In the meantime, perhaps the IETab extension might be useful. I've not
used it myself yet. I'm curious how the print mechanism in FF will
render it if you are using the IE engine. Perhaps I will play with it
later.Ok, its later now. :-)So I played with it & if I use the IE engine on that page, then the
print preview does display properly, showing *all* the images, for a
total of 6 pages. It makes sense, since I assume its using the IE print
preview function.You can get IETab here:
information on usage & known issues at the homepage:
--
Alex K.
Every time I try to play 1.20.2, eventually my game crashes to the launcher and gives the exit code -1073740791 and states that this issue is usually caused by an outdated graphics driver or a conflict with screen recording software. However, my NVIDIA driver is up to date and I don't have any screen recording software on my PC. Sometimes this crash occurs while creating a new world, other times the game is able to create the new world but will eventually crash after around 1-2 minutes of gameplay. I have tried:
When the issue first occurred I looked to see if my graphics driver needed an update and it did, so I updated it thinking that this was causing the problem, however Minecraft was still crashing with the same exit code even after I updated the driver, so I don't think it's the driver version causing this.
1. Using some screen recording or overlay program. GeForce Experience, Afterburner, OBS, etc. The exit code does also mention this so outdated drivers are unlikely to be the cause (unless you're still on seven year old nVidia drivers). If you're using any overlay or recording stuff, try without and see if that stops the issue. I was able to run these programs fine, but when I used Afterburner to record, it'd record fine, but if I recorded for too long, and then stopped, it'd trip it up.
a71949beef