fabiensanglard / gebbdoom Goto Github PK

As per title, in the PlayStation section, the quote from Tom Kalinske is missing the name at the end. Is that intended ?

Reported by xah liu via email

On page 226 of v1.2, footnote 19 "The Facts about Visplane Overflows" should be "The Truth about Visplane Overflows"

See:
https://soulsphere.org/mirrors/www.rome.ro/lee_killough/editing/visplane.shtml

First off, thank you for this book!

Suggestion on pg 277 - it would be more correct to define think_t as typedef void (* think_t ) ( void* ) ; to match its usage on this page.

It is currently reads as follows:

typedef struct thinker_s {
  struct thinker_s * prev , * next ;
  think_t function ;
} thinker_t ;

but in the instance of floor, it points to a function with the signature:

void T_MoveFloor ( floormove_t * floor ) ;

[...]

floor->thinker.function = ( think_t ) T_MoveFloor ;

There has been some simplification made to actual source code - the think_t type describes a union of function pointers, and the signature for the simplified think_t does not match its usage here.

Reported by Raigan Burns via email:

On p.266 you mention that when the Imp is in the stand state, "A_Look is called each tic trying to locate the player" -- actually this isn't true, the action functions are only called on the first tick of each state/frame, which means A_Look will only be triggered every 10 tics (since the Imp's standing states/frames last 10 tics).

Initially I was really confused about this design, since it means all those monsters with 3-tic duration A_Chase movement states will have their positions crudely animated at only about 11hz, which you'd think would look too step-y, but I verified this on a couple Doom modding forums: action functions are only called on the initial frame of the state, and monsters really do only move around the world at ~11hz (demons have 2-tic durations for A_Chase so they're a bit smoother).

(Also, since the initial tic value of each mobj is randomized when they get placed on the map, this means that it's sort of a work-balancing system since this way every monster isn't calling A_Chase every frame, they get spread around.)

On the angletoxTable.eps picture, shouldn't it be:

viewangletox[1028] = 319
viewangletox[3073] = 0

In the Game Engine Black Book v1.1, chapter 6.1.2, page 305, John Carmack is quoted stating this:

The little RISC engines were decent processors. I was surprised that they
didn’t use off the shelf designs, but they basically worked ok. They had some
design hazards (write after write) that didn’t get fixed, but the only thing truly
wrong with them was that they had scratchpad memory instead of caches, and
couldn’t execute code from main memory. I had to chunk the DOOM renderer
into nine sequentially loaded overlays to get it working (with hindsight, I would
have done it differently in about three...).

This is closely related to a previous paragraph on page 301/302:

While not wrong per se, I think this could use some clarification. The Jaguar's RISC engines could in fact execute code from main memory (DRAM) and were designed/meant to do so, BUT another one of those design hazards prevented this in practice:

So code could indeed be executed from main memory, but jump instructions were unreliable. Since jumps are an essential part of almost every algorithm, this practically renders code execution from main memory useless.

I think this is worth pointing out since it further explains why the Jaguar was so hard to deal with for developers (which in turn highlights what a genius John Carmack was back then to be able to pull it off). This was not just another minor design hazard that could be easily worked around, but instead a major deal-breaker. Even though execution from the RISCs' local scratchpad memory was much faster and the preferred choice, being able to execute code from main memory would have made development A LOT easier (i.e. simply use main memory during development, then chunk the FINAL code for use in scratchpad memory as an optimization step late in the development cycle).

Pages 270 to 272 display enemy hitboxes as circles, but in game they are actually squares. Though hitbox size property is still called "radius" in code.

Foone Turing recommends the use of 'they' to refer to themself, and 'their' machines, as acknowledged. I've worked on a patch; this issue is here for the sake of tracking the erratum.

See: #67.

The file clip4:c located at /src/code is an exact duplicate of clip4.c and to my knowledge (after a thorough search) unused in any of the .tex files.

I have been working on a fork of this repository for quite some time and the file checked out under Windows 7 with no problem when I forked around a year ago. Since then, I've deleted it and forgot about this but a couple of days ago I cloned again this repository to a new computer (so that I could build a fresh copy of the original) and the cloning failed while trying to check out the file under Windows 10.

Under Linux and Mac this checked out ok, but since the file seems unused, I suggest to delete it so that the repository can be cloned under Windows.

Here is the output I get:

$ git clone https://github.com/fabiensanglard/gebbdoom.git gebbdoom
Cloning into 'gebbdoom'...
remote: Enumerating objects: 5933, done.
remote: Total 5933 (delta 0), reused 0 (delta 0), pack-reused 5933
Receiving objects: 100% (5933/5933), 810.87 MiB | 615.00 KiB/s, done.
Resolving deltas: 100% (3912/3912), done.
error: invalid path 'src/code/clip4:c'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

Same as the PlayStation's RF modulator, the 3DO item I on the motherboard is the complete RF modulator, not just the out jack.

I've figured out that Ubuntu 20.04 (docker image) uses tkz-euclide version >= 3.02. This causes an error: can't find file `tkz-obj-angles.tex'.

Since version 3.02 \usetkzobj{all} is not necessary (see LaTeX can't find file 'tkz-obj-angles.tex').

At In figure \ref{COLORMAP.png}.

This place is being displayed in v2020.11.26 (the currently available PDF here) as this (page 230):

EDIT: Oh, sorry, this was already reported as #33.

It seems there is a mistake in internals.tex in the first line, which is:

'Then it took three months to proof-read it from October 2018 to November 2018'

That is at most two months, maybe some month is off or they really were two months.

Hi,

I was not able to generate the PDF file with all images. All SVG images were missing. While investigating, I found that the inkscape command given somehow did not work.

Replacing it with the command scheme inkscape --export-filename=out.png --export-dpi=300 in.svg worked.

$ inkscape --version
Inkscape 1.0.2 (e86c870879, 2021-01-15)
    Pango version: 1.48.1

Not sure how to fix the version detection line in make.sh.

This must be a proper noun, not a common one, I guess.

In the Game Engine Black Book v1.1, chapter 6.1.2, page 303, the reason for the Jaguar port of DOOM lacking music is explained as follows:

However, in AVGN's DOOM video that aired on 11/01, a rather different version of events is described (transcript of relevant section):

Shortly after that episode, I got a message from [level] designer Sandy Petersen, explaining the situation. I'll just summarize by saying it was a money issue. From what I was told, the contract with the composer meant having to pay him the same amount for the Jaguar version as the PC version, and clearly the Jaguar would sell far less copies. He ended by saying: "I know that's a shitty reason to leave out the music, but there you have it."

Video:
https://youtu.be/f5zyhC11hzQ?t=1120

Really interesting. Two entirely different reasons. Could it be that there were technical issues first (as described here), but THEN the financial issue came up, leading to simply disabling music and not bother with fixing the technical issues as it was no longer necessary?

Here's what I could find on the topic (probably what you used for the book in the first place):
https://forums.atariage.com/topic/69035-doom-music/
https://forums.atariage.com/topic/266578-why-no-music-on-jag-doom/
https://hackaday.com/2019/08/04/doing-what-id-couldnt-returning-music-to-jaguar-doom/
https://forums.atariage.com/topic/287323-enabling-music-sound-fx-mixing-within-jaguar-doom-source/page/2/#comment-4239037

In port_jaguar.tex, on the motherboard description, item B:

Channel switch, TV port

Shouldn't it be "RF modulator" ?

page 230: in figure ??

also on page 354 is a typo "required to coordinates 8 chips"

thanks for releasing these great books.

btw would it be possible to have additional smaller versions (like 150 dpi)? 300 dpi might be great to produce a physical book, but i don't think i can afford to keep a 160 MB pdf in my collection.

some more feedback: i had hoped the section dealing with the OPL2 in the wolf3d book would be a little bit more detailed. the doom book could illustrate a specific sbi instrument as an example and from what parameters it is composed of.