This is a strong argument for a broken status quo. It’s essentially dismissing many possible, tangible, in other places implemented approaches to improve representation, by essentially declaring that fixing the system cannot be done, or must first involve some completely new solution.
Whilst he owns a lot of Tesla, he doesn't have majority control - and has to get shareholders to vote on stuff like "Whether Elon should be given ridiculous bonus packages" and similar.
He's previously said both that he wants a single company and that he needs complete control of it.
Merge of companies at values I mentioned wouldn't give him over 50% ownership, but gives 51% of the votes
(Although I'd suggest you check my maths, people on the internet are sometimes wrong..)
I've also ignored the Tesla bonus plan - as it could be argued (and I'm sure it will be), that if it's Tesla that consumes SpaceX, then he's increased the market cap of Tesla. This then triggers new Tesla shares to be minted and given to him (last bonus plan), which both moves both more cash and voting out of the hands of the public into his.
Some might suggest this sounds like outright fraud - but his little fans will undoubtedly cheer this all through again..
Well thanks to the 60 minute game play and no saves, you only ever see the first four/five levels or so. It’s a great game, but that particular mechanic is …kind of annoying.
I remember it having saves? I'm not sure if that was an addition to the PC version or if I'm getting it mixed up with the sequel (which definitely did have them, but was also quite a bit harder so it _really_ needed them)
I personally am not a big fan of the banding effect due to small number of light levels. One way to reduce that would be to introduce a 2x2 dithering matrix grid across the whole screen that introduces small “luxel” deltas like 0.5, -0,5; 0.5, -0.5. Some pixels will be brighter, some darker, reducing the banding. Could also try different matrices.
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.
reply