Yes, the html version is very slow and doesn't look pretty. I am mostly using the source code (about equivalent to viewing "gbatek.txt" in your favorite text editor), and the no$gba.exe help engine (for having bold headlines and hyperlinks). But I've been wondering about making a version with multiple-htm-files for a while, too. And also about a few changes...profi200 wrote: ↑Sat Oct 17, 2020 8:05 am Recommendation (not exactly related to 3DS reverse engineering):
Split gbatek into multiple html files. It has become so big that lower end devices struggle with the site. Lower end for example being older ARMv7 tablets/smartphones or if you try to browse the site on a Raspberry Pi.
It even took seconds to load on a relatively modern i7 machine when i still had ADSL (got my connection upgraded to 100 Mbit/s VDSL recently).
New version with multiple .htm files
Just started working on that today. Current plan is simply making a separate page for each chapter (for each section with headline on gray background). Alternately, I could group all Video chapters or all Sound chapters into larger pages, but I tend to use only one chapter per page.
Apart from being faster to load the pages, I hope that it will also get more hits from internet search engines (which do currently more or less ignore gbatek, probably because they are considering it as too large to match to specifc search requests).
Old version with single .txt/.htm file
I'll keep hosting the old whole-document-in-one-file, too (and you could also keep generating it yourself using the "Save as help.txt/htm" function in no$gba help engine).
http://problemkaputt.de/gbatek.txt - text 3.8Mbyte
http://problemkaputt.de/gbatek.htm - html 4.7Mbyte
I am wondering what is making the page loading so slow. It might be my server being not the fastest one, or the network transfer speed, or browsers just being unable to display large documents. The first two issues could be avoided by saving a local copy of the htm/txt file.
Width Limit?
How would one limit the html page width to 80 characters? The various tables are using a nonproportional font with max 80 chars per line, and the line wrapping for the remaining text should be matched to that width (currently it tends to be 200+ chars/line when using a fullscreen browser window, which doesn't look nice).
Search Function?
Is there some freeware search engine for searching keywords/strings in multiple html files (eg. in /gbatek/*.htm), using php or so?
Blind People?
I don't know if there are many blind people interested in video game hardware, but just in case: What could/should be improved? I am aware of some possible issues:
The headlines are currently merely using large font size (or bold text for sub-headers), I am not sure if it's a real problem, but I guess they should be ideally marked as html headlines?
The tables are just plain txt without row/column markers (I think that's useful when copying chapters into text editors, eg. as source code comments), but for blind people it's probably almost impossible to keep track of the column widths. I am wondering if html tables with row/column markers are much easier to read though. Reading two-dimensional tables via voice-output is probably quite confusing.
Well, and then there are some ascii-art drawings, that's probably about as worse as gif's or jpeg's.
VG Wort Links
I am planning to add VG Wort links to the document, which will hopefully get me a little money per view. The money comes from copyright fees charged on selling storage media like harddisks, cdr's, sd cards, etc. in germany (accordingly, it's only working for german authors and views from german readers, and the money comes from the above fees: you won't have to pay anything or register/login when reading the html document).
Counting the number of views is done by linking to a 1x1 pixel image on the vgwort.de server. I haven't heard anybody complaining about that method yet.
Concerning privacy, it should be anonymous (and even if there would be a data leak, a list of IP addresses that have accessed gbatek is probably not so harmful).
The other issue is that the browser may be trying to download the pixel during offline reading, ie. bugging you to go online, or even automatically going online. The latter might be a problem if your internet provider is charging money per traffic or online time. Is there a way around that? Like adding a "skip-if-offline" flag to the vgwort-link?