This is interesting at the bottom of the readme file
Jez also offered this interesting BRender anecdote in an email:
When Sam Littlewood designed BRender, he didn’t write the code. And then document it.
The way most things were built at the time.
First, he wrote the manual. The full documentation
That served as the spec. Then the coding started.
The starting point for BRender was a sequence of software rendering experiments that grew from 'never doing it like our hand coded asm real mode x86 renderers ever again'. There were various diversions, eg: an achingly beautiful plane sweep that only rendered the visible parts of each output scanline, whilst murdering the cache so comprehensively that there are likely still lines waiting to be filled even now. Fortunately, to get the FX Fighter team going with something stable whilst debugging continued, I knocked up a Z buffer implementation, and was given a sharp lesson on caching when it blew all the previous attempts away (notably with consistency of performance).
Arriving at this point we figured there might be a product in it and looking at our own interaction with other libraries, it was clear that a manual was key to this. If I remember correctly, the API was a negotiation between myself proposing designs, and Crosbie Fitch documenting it - pushing back with ways to make things easier to explain.
It worked out very well, and we took it into later Argonaut hardware projects. The hardware guys had enough tools to do frame capture and replay from various games/apps at a low level, so were not desperate for a full software stack. The clients had very particular views about how APIs should look, depending on planned uses, in house style, compatibility etc. We would negotiate the API documentation back and forth - including lots of sample code.
This sample code was important, (and BRender would have benefited from more of this). I took lots of real use cases, then wrote proper code to implement them against the proposed APIs and included them in the docs as tutorial and example code. Importantly - they were a representative sampling of the anticipated uses (not just the easy ones), they were not 'handwavy' and included all appropriate resource management and error handling, and they had to read well on the page. As the API negotiation continued, so the examples and tutorials got updated.
This process also had the benefit that we only started investing in client specific software development once the project had got enough momentum (typically committing hardware NRE).
You start e.g. with a press release and then make your way backwards to the user stories and backlog.
It's a very useful approach to think big and focus on the problem instead of the many little issues that need to be solved.
The problem is that programming is still knowledge work. That means you can not specify everything beforehand without doing the actual work. (Like writing a novel, which can not specified before.)
The solution would imho be a good balance between description the big picture/desired result (good) and spec'ing out every little detail and screen in advance (bad).
I've done some hobby projects this way, of course I've allowed myself to go back and adjust the documentation where the implementation would be easier or simpler from only slight alterations of the workflow.
It's been very pleasant, and allowed me to make good sense of what I was doing and where I was going.
Right now, at work, I am getting insane with a task of re implementing some web forms that talk to shinier API. No documentation "just read the previous ruby server side validation code and put it on the js front-end". So I am hunting for hints and people to to be sure the code does what it intended to do. And I get cup sized eyes when asking for documentation :D.
The concept of "Readme Driven Development" [1] seems similar, but smaller in scope. I've actually found it very pragmatic/productive to, especially for smaller libraries, start with writing the Readme.
4. Download MSVC 2.0 (https://winworldpc.com/product/visual-c/2x), extract and install it into the 32-bit wineprefix
- Make sure you use `wine32 winecfg` and set the OS to Windows 95
5. Copy the files to C:\3d inside the wineprefix
6. Enter command prompt from wine (`wine32 cmd`)
7. `set include=C:\MSVC20\INC`
8. `.\setvars.bat`
9. `nmake`
Unfortunately wine segfaults for me when compiling one of the BRender files :'(
EDIT: Now I have Bren and Engine building! Studio does not build, reports that it doesn't know how to generate 'C:\3d\kauai\obj\wins\utilglob.obj'. Probably something simple...
This is awesome on so many levels. The bottom part of the read me says Jez San of Argonaut agreed to MIT the BRender part of it.
Argonaut rang a bell, and sure enough - Jez developed Starglider, one of my all time favourite games on the Amiga.
I can still remember it today, nearly four decades later: It was the first time I visited a new friend, who was the first in our neighbourhood to get the Amiga. He fired up Starglider- and I was simply blown away.
My C64 didn't cut it anymore - I just had to get the Amiga. An involvement in the Norwegian demo scene followed. This later had a big impact on my career as a SWE; thanks very much for this, Jez, if you're here!
Blown away foone managed to just ask for this... and get it... within a month timeframe. Gives me some hope we can get more ancient software open sourced in the future.
I cannot tell you how many hours I spent playing with 3DMM… once I figured out that you could make a gun by using a 3D “L” shape, my cartoons got violent and weird and I absolutely loved it, and I kept playing with it well into my teenage years.
I should see if I still have my CDs for it somewhere so I can run it in a VM.
This is incredible! I used to spend days making movies with this when I was a kid. Short clips and random stuff just to get laughs from friends and family.
There is a community still going around this where people post there movies and stuff - https://www.3dmm.com/
Same! I used to run a site for highly rated 3DMM movies that begun becoming popular until someone flagged it for copyright infringement and Xoom terminated it without warning while I was on vacation, tried showing it to friends but it wouldn't load :( https://en.wikipedia.org/wiki/Xoom_(web_hosting)
I then attempted to make a technically complex movie myself, and of course my HDD crashed - seems as a kid I could never catch a break when it came to technology :P
This is astounding. Truly above expectations. I hope it’s not the last such stunning open sourcing from Microsoft, as there is so much historical stuff I’d really like to explore, but I can’t complain.
Congrats, this type of release is really hard to do and usually gains you nothing apart from that impossible to measure reputation. Kudos to all involved.
Congrats, microsoft! I don't know how popular, useful or powerful this software is but, although not a microsft flagship, I love when companies open source their software that is no longer a huge profit margin. At the least it is better than see it dying deep into a drawer.
Absolutely. I also love it for exactly that reason. It is no longer a financial asset, it is no longer competetive advantage and not a unique jumpstart which can lead to one.
[+] [-] svag|3 years ago|reply
[+] [-] samlittlewood|3 years ago|reply
The starting point for BRender was a sequence of software rendering experiments that grew from 'never doing it like our hand coded asm real mode x86 renderers ever again'. There were various diversions, eg: an achingly beautiful plane sweep that only rendered the visible parts of each output scanline, whilst murdering the cache so comprehensively that there are likely still lines waiting to be filled even now. Fortunately, to get the FX Fighter team going with something stable whilst debugging continued, I knocked up a Z buffer implementation, and was given a sharp lesson on caching when it blew all the previous attempts away (notably with consistency of performance).
Arriving at this point we figured there might be a product in it and looking at our own interaction with other libraries, it was clear that a manual was key to this. If I remember correctly, the API was a negotiation between myself proposing designs, and Crosbie Fitch documenting it - pushing back with ways to make things easier to explain.
It worked out very well, and we took it into later Argonaut hardware projects. The hardware guys had enough tools to do frame capture and replay from various games/apps at a low level, so were not desperate for a full software stack. The clients had very particular views about how APIs should look, depending on planned uses, in house style, compatibility etc. We would negotiate the API documentation back and forth - including lots of sample code.
This sample code was important, (and BRender would have benefited from more of this). I took lots of real use cases, then wrote proper code to implement them against the proposed APIs and included them in the docs as tutorial and example code. Importantly - they were a representative sampling of the anticipated uses (not just the easy ones), they were not 'handwavy' and included all appropriate resource management and error handling, and they had to read well on the page. As the API negotiation continued, so the examples and tutorials got updated.
This process also had the benefit that we only started investing in client specific software development once the project had got enough momentum (typically committing hardware NRE).
[+] [-] mkreis|3 years ago|reply
You start e.g. with a press release and then make your way backwards to the user stories and backlog.
It's a very useful approach to think big and focus on the problem instead of the many little issues that need to be solved.
The problem is that programming is still knowledge work. That means you can not specify everything beforehand without doing the actual work. (Like writing a novel, which can not specified before.) The solution would imho be a good balance between description the big picture/desired result (good) and spec'ing out every little detail and screen in advance (bad).
[+] [-] dusted|3 years ago|reply
It's been very pleasant, and allowed me to make good sense of what I was doing and where I was going.
[+] [-] johnchristopher|3 years ago|reply
[+] [-] walski|3 years ago|reply
1: https://tom.preston-werner.com/2010/08/23/readme-driven-deve...
[+] [-] magpi3|3 years ago|reply
[+] [-] Narann|3 years ago|reply
[+] [-] wizzledonker|3 years ago|reply
1. In linux
2. Install wine 7.5 (other versions may work, this is what I used)
3. Create a 32-bit wineprefix on a *case-insensitive* ext4 drive (https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...)
4. Download MSVC 2.0 (https://winworldpc.com/product/visual-c/2x), extract and install it into the 32-bit wineprefix - Make sure you use `wine32 winecfg` and set the OS to Windows 95
5. Copy the files to C:\3d inside the wineprefix
6. Enter command prompt from wine (`wine32 cmd`)
7. `set include=C:\MSVC20\INC`
8. `.\setvars.bat`
9. `nmake`
Unfortunately wine segfaults for me when compiling one of the BRender files :'(
EDIT: Now I have Bren and Engine building! Studio does not build, reports that it doesn't know how to generate 'C:\3d\kauai\obj\wins\utilglob.obj'. Probably something simple...
[+] [-] coldpie|3 years ago|reply
[+] [-] anthk|3 years ago|reply
Just create a disk image and mkfs.ext4 it :)
[+] [-] LowLevelMahn|3 years ago|reply
[+] [-] sundvor|3 years ago|reply
Argonaut rang a bell, and sure enough - Jez developed Starglider, one of my all time favourite games on the Amiga.
I can still remember it today, nearly four decades later: It was the first time I visited a new friend, who was the first in our neighbourhood to get the Amiga. He fired up Starglider- and I was simply blown away.
My C64 didn't cut it anymore - I just had to get the Amiga. An involvement in the Norwegian demo scene followed. This later had a big impact on my career as a SWE; thanks very much for this, Jez, if you're here!
[+] [-] lproven|3 years ago|reply
But wireframe only, I think?
I think Starglider 2 was inspired in part by Zarch on the Archimedes, and the free Lander demo that came with every Archie.
https://www.youtube.com/watch?v=mFwpsb75omg
It is hard to put into words how amazing it was to see this running, live and playable, on a home computer in 1987.
Jez San also co-designed the SuperFX 3D accelerator chip in the SNES game Starfox. That evolved into the ARC RISC CPU family.
An ARC core was the Intel Management Engine chip in Intel CPUs before they switched to an x86 ME controller running Minix 3.
https://en.wikipedia.org/wiki/Intel_Management_Engine#Hardwa...
And that ARC core ran ThreadX, which is the same OS that runs on the GPU of every Raspberry Pi.
https://en.wikipedia.org/wiki/ThreadX
San offered me a job once, nearly 30Y ago. I should have accepted it. :-D
[+] [-] JezSan|3 years ago|reply
[+] [-] dubswithus|3 years ago|reply
https://funfair.io/
[+] [-] drewtato|3 years ago|reply
Context: https://twitter.com/Foone/status/1521583448795672576
[+] [-] ocdtrekkie|3 years ago|reply
[+] [-] tombert|3 years ago|reply
I should see if I still have my CDs for it somewhere so I can run it in a VM.
[+] [-] _s_a_m_|3 years ago|reply
[+] [-] Scalene2|3 years ago|reply
[+] [-] exikyut|3 years ago|reply
Seriously. It'll likely both take a little while, yet be usable much sooner than you expect.
[+] [-] steve_coral|3 years ago|reply
[+] [-] voidfunc|3 years ago|reply
[+] [-] rightbyte|3 years ago|reply
[+] [-] matthewhartmans|3 years ago|reply
There is a community still going around this where people post there movies and stuff - https://www.3dmm.com/
Oh wow, good times!
[+] [-] Lorin|3 years ago|reply
I then attempted to make a technically complex movie myself, and of course my HDD crashed - seems as a kid I could never catch a break when it came to technology :P
[+] [-] LowLevelMahn|3 years ago|reply
hope they will every release the good old Basic Compiler bascom/basrun stuff
[+] [-] jchw|3 years ago|reply
[+] [-] Aissen|3 years ago|reply
[+] [-] marcodiego|3 years ago|reply
[+] [-] oaiey|3 years ago|reply
[+] [-] o_m|3 years ago|reply
[+] [-] spacechild1|3 years ago|reply
[+] [-] als0|3 years ago|reply
[+] [-] Lorin|3 years ago|reply
[+] [-] tombert|3 years ago|reply
> The infamous Comic Sans font also made its first appearance in 3D Movie Maker
[1] https://en.wikipedia.org/wiki/3D_Movie_Maker
[+] [-] eurasiantiger|3 years ago|reply
[+] [-] iamcurious|3 years ago|reply
[+] [-] arriu|3 years ago|reply
[+] [-] pkamb|3 years ago|reply
[+] [-] AndrewOMartin|3 years ago|reply