In my experience, for every customer support agent that really wants to help people and cares about their problems, there are at least ten who don't even read what you wrote and answer with prefabricated blocks of text that have little to do with what you asked. If AI customer support actually tries to understand what I ask of it and help me, and there are still (motivated) humans available for the more tricky cases that AI can't handle, that might be a win...
Part of the problem is that it wasn't possible to upload it to YouTube until recently (and someone from Germany could still demand for it to be taken down or made unavailable in Germany), while also, being almost 100 years old, it was not released commercially - which both conspired to condemn it to obscurity.
Animation isn't just hand-drawn animation, it's any kind of movie composed from individual still images. And stop-motion animation is a subcategory of that, no matter if you use clay/putty (like in Wallace & Gromit), Lego figures or paper cutouts (like in this case or also on South Park).
This depends whether you have one of those barriers made of bollards that raise out of the ground (expensive, hard to retrofit on an existing parking structure), or the kind where an arm lowers across the road (cheap, trivial to retrofit)
I think such barriers are usually considered permanent and must always be overcome. You get over a barrier. So it is more like a wall or hurdle. In the metaphors of difficulty it is assumed there will always be some residual difficulty so there will still be a barrier, but one that is easier to get over, so it is replaced with a lower one.
[citation needed] - if I look at https://en.wikipedia.org/wiki/Casualties_of_the_Russo-Ukrain..., the only source that says that there are more than 1 million killed and wounded (!) Ukrainian soldiers is the Russian Ministry of Defense, which I wouldn't consider very trustworthy...
It's also interesting that, while the "ally" curve is going down for all included countries, in some countries the "partner" (which is a weaker form of ally) curve is going up to partly compensate for that, while in others (mostly southern European, plus Switzerland and, of course, Denmark), it's also going down.
> If you have a good architecture and keep good code hygiene
That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.
Then redesign the architecture. No need to go for a full rewrite as it can be done progressively. One thing I’ve seen is that people can be afraid to delete code, even if it’s not used anywhere.
"Vintage" usually refers to actually old stuff, while "retro" refers to new stuff that looks/sounds/feels like old stuff. So GentleOS is a retro OS designed to run on vintage hardware.
(That distinction wasn't clear to me either, so I had to look it up - TIL).
That’s not true in computer terminology. “Retro” has a long history (“vintage” you might say haha) of referring to old hardware and software.
Just type the word “retro” into YouTube (for example) and you’ll see thousands of videos from hundreds of channels spanning decades talking about old games and computers.
I just noticed that this might be one of the rare shooters with a female protagonist: the cat has a calico pattern, and those are almost always female (https://en.wikipedia.org/wiki/Calico_cat).
It's not that rare, is it? Off-hand, and very mainstream; Perfect Dark, Mirrors Edge, Dishonored (don't remember if it's the first or second one), Metroid and more are all kind of "shooters" with female protagonist, although maybe Mirror's Edge is more just "first-person" than "shooter" to be 100% accurate.
Not to mention the large selection of "RPG + FPS" where you can be either man or woman.
---------
Seems the author also realize the thing with the pattern and likely gender of the cat:
> After all, I do need to give the protagonist his fair share. [image] (Yes, I know it's a female, but call it convention rooted in dialect.)
> The character of Prisoner 849 is commonly speculated to be Gina, as her model (Female 1) and skin are the first character to appear in alphabetical order; this is even reinforced by UnCreature giving the female player a bio while the male player bio just reads "See Female Player". However, the character of Prisoner 849 is completely up to the player's choice, hence the use of neutral nouns in this article.
Mirror's Edge has a female protagonist, but it's not an FPS (First Person Shooter). It's a parkour simulator which technically lets you shoot a gun in limited sections of the game, but the protagonist is a pacifist and you get a bonus for decommisioning guns rather than firing them.
So it looks like the two categorisations, for the most part, don't intersect.
Notable counterexamples would include Rise of the Triad, Ion Fury, No One Lives Forever, Wolfenstein: Youngblood and Far Cry 6, but definitely rare. You'd be clutching at straws to describe Portal or Alien: Isolation as FPS (they're a puzzle game and survival horror game respectively), likewise the Resident Evil / Clock Tower / Fatal Frame / etc. games with the novelty option of switching to first-person view, they're naturally third-person perspective. Left 4 Dead has one female character out of four you can play. You might count that one DLC for Bioshock: Infinite where Elizabeth gets a shot (https://www.youtube.com/watch?v=1E1lh-pb6Is). You might count the few FPS RPGs that there are with customisable characters (so yes Fallout, but not Mass Effect as it's third-person). But female protagonists are massively more prevalent in survival horror, metroidvania, third-person shooters (Tomb Raider, Monster Hunter, Horizon Zero Dawn, etc) and other genres besides FPS.
> They're definitely rare. Mirror's Edge is almost 20 years old
You probably didn't play many FPS recently: from the top of my mind, CS2, Battlefield {1, V, 6}, CoD {BO3, Vanguard, MWIII}, Control, the Borderlands, Far Cry {5, 6}, CP2077, Fallout {3, NV, 4}, Destiny, Prey, Valorant, Rainbow 6, Apex, Overwatch, all have female player characters.
And if CS2/CoD/BF/Valorant/Destiny/Apex have female players, that's more or less 90% of the current market.
I took a glance at the the most played FPS list from Steam[0], but I was too lazy to scroll far enough to find one without a playable female character.
> Reaching back that far for an example just reinforces how rare it is.
Choosing one specific example when I also made more recent ones, isn't such a big dunk you think it is.
> If you tally all the FPS releases in a given year, a supermajority are going to have male protagonists.
Sure, I agree, I'm not saying it's more popular, just that I don't think it's that rare, but I guess ultimately I'm a bit nitpicky (sorry) and we're just disagreeing with the specific definition of "rare".
A lot of boomer shooters nowadays have a female protagonist, e.g. Selaco[0], Supplice[1], The Citadel[2] and its sequel[3], Zortch[4] (and its upcoming sequel[5]), Nighmare Reaper[6], COVEN[7], Viscerafest[8], Hedon[9], etc. If anything i'd say that nowadays there are way more boomer shooters with female protagonists than not :-P (combining the tags "boomer shooter" with "female protagonist" on Steam search gives 143 results, though that includes games where you can either choose your character's gender or you play as a woman for a part of the game even if you play as a man for most of it).
So a bit less than 1/10 of the games tagged with "boomer shooter". With your caveats above about being able to choose a gender, or a single brief segment where you're a lady in a game where you're mostly a dude. Is that a lot? I dunno, doesn't feel like a lot to me. Probably feels like a lot to the people who inevitably show up in the Steam discussions of any successful game that makes you be a lady for most of its length and complain about it being "woke", even one game with a female protagonist seems to be too many for them.
I doubt it was intentional, but in general, I am not impressed by that and don't find any value in that. Same with Hollywood's depiction of women knocking out guys twice their size. Unrealistic, ridiculous, and harmful.
not harmful. why should women in action films need to be held to a higher standard the men?
Hollywood's depiction of action movies in general is unrealistic. Stereotypical Good Guy gets in a fist fight with a Random Thug, and after trading blows for a while the Good Guy knocks out Random Thug and carries on with the rest of the movie without a problem. No bruising, no eye swelling shut, no broken ribs restricting movement or breathing, no loose teeth, no broken fingers, no sore wrists from mis-angled punches.
This is taking a lot of inspiration from Doom, but the actual raycasting engine is more like Doom's predecessors, the most well-known of which is probably Wolfenstein 3D: perpendicular walls, constant floor and ceiling height. Wolf3D didn't have textured floors and ceilings because of performance reasons, but several other similar games had them. Doom and IIRC Duke Nukem as well used a BSP engine which was much more flexible (walls could intersect at any angle, variable floor and ceiling heights), although the levels were still "flat" (you couldn't have several "stories" inside a level, e.g. you couldn't design a bridge that you could walk over and under).
The Build engine didn't use BSP, it treated connections between sectors as portals and rasterized the walls as (90 degree rotated) trapezoids while performing clipping against those portals. This allowed it to have dynamic wall geometry (e.g. moving trains, rotating light fixtures, etc) as well as "room-over-room" setups as long as you couldn't see both rooms at the same time (in both Blood and Shadow Warrior they found a workaround for it allowing to create more "3D" spaces by making identically shaped sectors with the floor of one sector acting as a portal to the ceiling of the other sector - supposedly this wasn't "natively" supported by the engine, but it was flexible enough for the game studios who used it -without even having access to the source- to do it themselves).
The first level of Duke Nukem 3D does use a few Build tricks - e.g. another one is that sprites can be "axis aligned" instead of following the camera and they can also have collision - this can be used to create rudimentary 3D geometry by treating each sprite as an axis aligned quad and in the first level it is used to make a bridge between two buildings (right before the level exit button).
I always loved that the bridge you mentioned could take damage and fall down, screwing you over in the very first level, unless you knew where the Jetpack was stashed.
The funny thing is that looking backwards, I would never use a grid of squares for a raycaster like wolfenstein3d did.
If I were to do a raycaster today, I would use convex sectors with portals, basically like duke nukem, but constant wall heights. You can do drawing very simply by just doing a linear pass across the sector, recursively stepping into other sectors.
Then you can at least do arbitrary level geometries.
Yeah, that is basically what i did around 2009 when i was making a 3D engine in Haxe for Flash, RayFaster 2 (it was the successor to another Flash game engine, RayFaster, which did Wolf3D-like raycasting and i used to make a simple FPS[0] though with Flash's input limitations i couldn't do mouselook and didn't feel that great).
The engine used Build/Doom-like maps and would simply raycast against the camera's current sector (sectors could be any shape not just convex) and used connections between sectors as portals to recursively follow the (2D) map until it hit a solid wall - so basically Build's portal rendering approach except using raycasting instead of trapezoid rasterization. It could also do sprite rendering (you could have both sprites facing the camera and "aligned" sprites that could be used for decals) and even had some simple 3D model rendering (the triangles were sorted and clipped against the portal during rasterization). Unfortunately Flash isn't available in browsers anymore and Ruffle isn't compatible with it (it can run the engine -much slower than real Flash- but the palette is all wrong), so i took some shots using the standalone Flash "projector"[1][2][3][4]. Also making maps for it was certainly much more laborsome than making maps for a Wolf3D-like game and that combined with me losing interest in making Flash games meant i never made a game with it.
It really doesn't. I would argue that convex sectors with portals could be quicker than casting rays across a grid for every pixel column, except for some degenerate cases. This is because for any pixel column in-between the boundaries of wall segments, there's virtually no work to be done (O(1)), compared to the work of casting a ray along the grid O(n).
Btw, 286 played wolfenstein rather poorly. The 386 is rather more appropriate.
Wolfenstein was built in a couple of months by a then 21-year-old Carmack. He didn't focus on optimizing levels until Doom.
Yes, I played it at the time on both a 286 and a 386. You might be right, although you're describing an algorithm more like what Duke3d used rather than raycasting in that case. I was talking purely about raycasting. So it sounds like a misunderstanding on my part.
It's true that Carmack has said several times, including in the readme to the source release of Wolf3d [0], that a BSP-based renderer might be faster than raycasting. He used a BSP tree based renderer for the SNES port of Wolf3d because the CPU was even slower, so I suppose that answers it! There's also a note in the GEBB page 164 from Carmack where he says it was slower than "looping through a few long wall segments". [1]
Early alpha versions of DOOM used a sector-based rendering technique, maybe like what you're describing, which ultimately was too slow [2]][3]. Then Carmack switched to BSP trees after doing the Wolf3d SNES port.
I think it would be pretty interesting to implement the same game with both a raycasting approach and a BSP or Build-style portal/sector approach and compare performance on a 386. DOOM ran terribly on a 386 but it did a lot more than Wolf3d, so it's not a great comparison. Catacomb 3D didn't use raycasting (it used a wall span rendering techniqe) and ran better than Wolf3d on similar hardware, but it had a bunch of glitches. But Carmack says they were due to lack of experience rather than the technique itself.
Anyway thanks for challenging my assumptions. This'll go on my todo list!
Thank you for all the interesting references. I had almost forgotten about the BSP-SNES port.
I think they main concern when doing sectors + portals for a wolf3d-type 3d engine is how much word is done when 'stepping into' portals. basically it requires changing the clipping range [x0, x] of the portal, and quickly finding the next visible wall segment. the clipping could actually be done in 'angle space', not even using vectors. That is, wall edges/"vertices" should be represented as [angle,distance]. I have also been thinking about how much of that math pipeline could be done using specialized 8-bit values and LUTs.
I have been thinking about trying to get something running on very slow hardware, although at some point the problem is more drawing on the screen quickly, not the renderer.
I saw recently on the website of the guy who built the Build engine that licensees got some .c files and some .o files (with the rough breakdown being game code in .c files and engine code in .o files) but I guess if you knew enough you could hack around.
Though it must be said that Duke's flexibility came with a tradeoff - while BSPs will find a leaf node in log(n) time, no such guarantee exists for Duke and its up to the mappers to optimize the maps so that the renderer doesn't need to traverse a large amount of sectors.
GLQuake introduced the r_wateralpha setting, which allowed transparent water, but the maps were still compiled with visibility calculations that assumed the water surfaces were opaque. You got visual artifacts unless you enabled r_novis to ignore the pre-calculated visibility calculations. Modern computers can handle it, but this was a heavy performance cost at the time.
To work around this, people used an unofficial tool to patch the maps to support transparent water:
Don't forget the optional voxel models! They did some really cool stuff with Build. I loved some of the creative uses of things like controllable vehicles (sometimes with guns!).
I think the argument could be made both that both engines are raycasters, though they don't cast rays over pixels, but horizontal 2D spans (where each ray is going to end in the same sector).
With the data structure being more efficient, and doing less overall work, I think this part of the Doom/Duke engine might even be faster than than Wolf3D
With regard to floors, afaik even DOOM didn't do them correctly. With vertical walls, the perspective divide needs to be done only once per column of pixels for a given wall segment.
For floors, unfortunately there's no such luxury, and if I remember correctly DOOM subdivided floors into patches, and only did proper perspective at the corners, and interpolated inbetween.
For floors the perspective divide is once per row, just like for walls it's once per column.
The BSP may have led to some floor subdivisions, especially as it needs convex sectors. I don't remember if the engine would coalesce adjacent floor spans into a single one, but I hope it did.
That would only be true if a row (by which I mean a scanline) would be equidistant in view-space depth across its whole length, which is not quite true. While a column of pixels for a wall is (as long as you dont tilt the camera).
And it looks to me like we are mapping each row with a constant y, calculating the "distance" (thus scale factor) only once using just the vertical slope for the row.
For the record, there were constant-Z full 3D engines in the late 90s, which would find the correct axes on screen to render perspective-correct textured triangles using oblique spans of pixels. They were incredibly complicated and prone to holes at the slightest numerical accuracy, but they were a sight to behold. Constant-Z meant not just saving on perspective divides, but also easy Z-buffer and depth-based fog.
reply