Love how 'But, Can It Run Doom' has become such a landmark moment in a project's existence. Is like when a computer language gets to become self-hosted, a sign of maturity.
John Carmack made doom run on my 486 25mhz , that was impressive, makng it run on a 160mhz state of the art instruction set processor? meh i guess thats impressive(i couldnt do that). But a terrible benchmark for any aspiring programmmer. Make doom run at 30fps on my 486 25mhz machine and ill be impressed, John couldnt do that.
Im so glad to see new videos from you. Im a 19 year old student from germany and Im into embedded programming and electronics. Often when i think that something is just to complicated to learn or to program, i come back to your older videos to realize that with enough efford I may be able to achieve exactly what i want or even more. What you've created is incredible...
The only thing that makes things complicated is people who don't really understand what they're doing. If you just start digging and using and growing, eventually your sense of what is intuitive will begin to mirror the world we live in. Don't accept something being "complicated" as an answer. Dig. Because if something is _actually_ is complicated, it means the people who made it didn't understand what they were doing. And you can do better.
@@CNLohr In most of my drawback in programming is I don't read (or memories) the datasheet(reference) for the language/library/device I wanted to work on, it the most reason why I don't program in C/C++
@@مقاطعمترجمة-ش8ث If you read the datasheets, they start helping you "think" like the designers/authors thought. It is hard to read/process, I know, but that's because it's breaking your brain from the natural way you think, to think in the way that the other engineers think. And it's incredibly valuable to change the way you think.
I'm trying to design a CPU that works with RISC-V instruction set with a small engineering undergrads team and you came back with RISC-V content. What a coincidence!
RISC-V is so fast and efficient that you're always going forwards, at speeds never known! *that's* why pressing player back makes you faceplant the wall
Crocodiles with big mouths, long legs and short arms will be cut down in no time, maybe it will pay off if you start expanding what you know instead of getting stuck.
What @@CNLohr said. If you love programming, you'll LOVE low-level development once you get it. It's often much simpler than high-level frameworks and that stuff.
@@0ri3z3r0 I wouldn't say convoluted. But maybe not-obvious, and you're DEF right that there's a huge lack of learning resources. Everyone wants to make a video about some new javascript framework, but no one's excited to explain really deep principles from 1994.
You could achieve a sort of temporal antialiasing by instead of skipping entire swaths of pixels - cycle through which one you're actually using for the ASCII output, to get a sort of temporal dithering. Bayer matrix could spread out the order that pixels are sampled each frame to create the fore/back ground colors for each ASCII, rather than just cycling through them in X and Y. What would be even cooler is if each Doom frame was rendered by a handful of these temporal dither frames - if the ASCII output can be faster than the Doom render, by several frames.
This sounds like it would be super flickery, and I don't think there is enough time to anything like stacking frames or doing much in the way of effects.
@@CNLohr I think they are suggesting to write to the terminal so fast that the ASCII characters blend in with each other. (Imagine reduced opacity on multiple overlayed text characters where lower layers show through) And all that sorting stuff is probably to get the best combination of characters to layer.
@@CNLohr Instead of cycling through the input pixels to an ASCII character you could just average all of the pixels' RGB values that contribute to an ASCII character. That would be more stable. There's also room for employing the various box drawing ASCII characters and effectively treating each ASCII character more like two pixels instead of one. Figuring out the optimal way to represent a set of pixels with an ASCII character could be a whole project unto itself! I definitely think averaging the pixels into the output ASCII character is the way to go though. Outright discarding pixels just feels wrong!
I mean I could argue that SDL, if you just want to push pixels to a window, is so easy that a braindead monkey could do it, and you'd have to be just as lazy as one to be scared by it.
Doom on 512k is very interesting, I was planning on getting Doom or a Doom clone to work on my 65c02 board at some point but I'd have to design a 512k bank switching system and make the memory manager work with bank switching, which sounds like a nightmare, maybe in the future though
Rocketing forward when pressing back sounds like that one issue with the 'ticcmd_t' struct, which has member variables that are defined as 'char' without an explicit signedness: on platforms where char is unsigned by default, you'll experience that bug. Making the chars explicitly signed fixes the issue.
protip: basically all terminals support 16-color, not only 8 color, even heckin' linux TTY does! also, you could probably make an optional 256-color mode, which would look a *LOT* better, visually
@@CNLohr fair at that, although terminal emulators can usually be set to allow pretty fast speeds...also, I've seen people use the half-block characters (one half background color, one half foreground color), is the current way getting more detail, or is that also excess data transmission? it'd need slightly more computation I suppose, but effectively give a canvas of pixels, twice the height and same width as you'd fit with normal characters (with square pixels!)
Now i am intrigued what performance would be if we used an RP2040 with some external serial RAM and VT100 emulation video output on VGA. Would the system still be usable as a tiny cheap Linux PC or not? EDIT: Defining usable, snappy enough that some editor like Tilde and tools like Midnight are not laggy to use, my benchmark would be some XT class machine running MSDOS with the QuickIDE and Norton Commander. Stuff takes some time to load but when up is snappy to use.
I'd be curious to know what drives you into creating mind blowing side projects like this. Taking on a challenge, flexing, pure curiosity, excuse for not working on some even more complex project, just a way to relax or something else? Regardless of the motivator, so much fun even if 97% goes over my head.
I know a colleague at uni, that ported DOOM to RISC-V for a demo of our RISC-V CPU. I now feel stupid, for not asking him in time to upload the code to the uni repos. Your version in the terminal runs much faster btw. But our code was also largely unoptimized (I suggested making use of our extensions, as we were using an FPGA with a bunch of custom peripherals, but he was like: "Nah, this is more or less the original DOOM. Using our PPU for the color palette and our extensions would be cheating"). But yeah, our 50MHz RISC-V CPU running on an FPGA runs DOOM in a playable manner, as well. Always funny to see other people doing the same stuff.
Could that problem you describe at the end be a similar issue with signed/unsigned integers? Like, changing the position by x when moving forward, and x times -1 when moving backwards?
What's the font we see when you're looking at the makefile at 6:40? It looks so much better than what I'm using at the moment. Yes, I realise the video is about your work on doom for your emulator, and it's amazing what you've achieved, but that font looks fab.
I had the same bug launching the player forward on pressing backwards on a Raspberry Pi with my doom port! It's simply to do with Doom assuming a char is signed in the ticcmd_t struct in d_ticcmd.h. I fixed it by explicitly changing "char" to "signed char" haha
You can emulate A extension if code runs in Machine mode and interrupts are disabled. In lower privilege modes atomicity can't be guarantied because of M mode interrupts
Interesting point. I hadn't considered that. Are you pointing out that the atomicity of the load/store semantics will cause an issue if I am not properly emulating the memory slot? Do you mind opening a new github issue for this and explaining?
There's a whole library dedicated to generaring optimal ASCII patterns out of pixel graphics, its called aalib. You should try using it. There's also a very cool demo using it called BB
@@CNLohr I never used it but I was under the impression that it just takes a pointer to a framebuffer and outputs the characters so it would be perfect for this. In fact you can already run doom on aalib in a way, because SDL supports it as a video driver, so chocolate doom using SDL can run in a terminal using aalib. Great channel btw, ive watched a bunch of your videos recently :)
@@CNLohr This also reminds me of the world cup ASCII telnet server from 2006. I don't know the Doom source code, which file contains your code for choosing the characters and letters for a given block of pixels?
So, now that you have it running in text mode, and without MMU, would it be possible to make this DooM run on a pre MMU capable x86 such as the i80286 or even 8086? I think the entire retro community has been waiting for that for a long time! Please say yes!
You should make a video on how to learn shaders in VRChat. I'm a computer science student and I really want to experiment with shaders [already been building with avatars/worlds] but I can't find any good resources on how to get started with shaders. I'm sure a lot of people would appreciate this from someone with your level of experience.
I have thought about this a lot. And talked to others in the community. But I haven't had the "hook" to make it happen. It's a lot of work to make videos, and unless I'm relatively confident they'll get a lot of views it's hard to make them.
If you want to make it look much better, use any 16 color wad as Doom palette is too oscure, and avoid using any text characters, half block characters are way better
@@CNLohr it's interpreter, but with basic block caching (so I didn't parse instruction every time) and mmu caching(tlb's), so performance varies a lot when linux starts to flush caches. Best case is softpipe rendering glgears 100 million instructions per second, but it drops to 20mips on systemd startup. Also, I my rootfs is nfs, for ease of development
@@CNLohr also, it depends on how close to so spec you wanted to be. For example: every target of branch instructions should be 4 bytes aligned (2 bytes if C-ext supported)
7:34 oh god that's the worst. I immediately thought "oh, a different language would catch that" but would it? u32s can always be implicitly cast to i64s because an i64 can hold every possible u32 value-so no, it wouldn't. I guess one thing that could prevent that from being an issue is storing registers as as a union{u32, i32} instead, that way you have to select one each time. especially since so many riscv instructions are signed only or support signed ints. not sure though.
oooh, emDOOM looks really interesting. but the 5MB WAD file seems like a major bottleneck for most if not all Microcontrollers (what low to mid tier MCUs have >5MB of flash?) and Von Neumann based DIY systems (68k, 65c816, Z80-ish, etc) where Program and Data share the same memory. i wonder how small the WAD would be if you cut everything except the first episode, or even just everything except E1M1 and all required graphics for it.
@@CNLohr i grabbed the full Ultimate DOOM IWAD and used SLADE to remove all music and sound effects, all levels except for episode 1, and all unused graphics. the total file size is down from 11MB to 7MB. (where did you get 5MB mentioned in the github from?) the main bulk are the graphics (~6.1MB). reducing all of them from 256 to 2 colors would cut the size down a huge amount... but then the game would be completely monochrome. so maybe halfing the resolution and going from 256 colors to 16 would be a better idea. in theory it should have the same decrease in file size as going monochrome. or maybe some basic file IO would be better to not have to load all levels and graphics into RAM at the same time
try plane-ray intersection culling with sphere entity volumes (another type of bsp tree, more general hierarchical volumes tree) instead of normal doom render method
its real 3d, not 2.5d, even if rendering vertical lines (the plane-ray of a vertical line of the monitor), more like quake but feels like doom/duke3d, its a specific case of a ray-caster
meh its a text mode pixel manipulation, only limit is how many character fonts you can have at one time, or just draw one text box at a time, then draw it, draw next, if you cannot access pixels directly
Heh, this reminds me, when I used to draw graphics in Pascals by writing to B800:0000 (or what was the magic number) with ascii. Easy to do Tetris, Sokoban, or Snake. Really nice job with the emulator and bughunting.
Yup! Or, I grew up with an 8086 with built-in 128k EGA. You can write to all of 0xA000:0 to 0xB000:FFFF, 640x350 at 16 colors, two pages. What luxury! Or should I say &HA000 because I was mostly poking around in QBASIC at the time (yuck!). Oh but it was so weird, with the bitplanes. Took me a while to find out you need to talk to the graphics registers too, to draw any colors.
@@CNLohr yeh, I think it was the 80x?? mode? I remember having to switch. Ive just checked B800 is really the magic memory address in pascal. Im probably just remembering 16bit version. So just B800.
Why is everyone so interested in RISC-V lately? I've barely even heard of it until recently, and I figured that ARM was the superior RISC architecture anyway. What's so special about RISC-V?
It's that the ISA, spec, toolchains are all open source. So if you want to work on a RISC-V you don't have to learn absurdly specific and proprietary stuff just to use the base CPU.
@@CNLohr don't take this the wrong way, but I would shoot myself if this was the only terminal font available. Or switch jobs I guess The font is obviously no barrier to you, I was just curious if it's a necessity
Love how 'But, Can It Run Doom' has become such a landmark moment in a project's existence. Is like when a computer language gets to become self-hosted, a sign of maturity.
Me, too! Self-hosting would be fun, too.
It's the programming/gaming equivalent to "But can he beat Goku though?"
@@flavourously nah, that one gotta be "can it run crysis?"
But can it display bad apple? Yes it can if it has some way of interaction and 2 colors at minimum it can.
John Carmack made doom run on my 486 25mhz , that was impressive, makng it run on a 160mhz state of the art instruction set processor? meh i guess thats impressive(i couldnt do that). But a terrible benchmark for any aspiring programmmer. Make doom run at 30fps on my 486 25mhz machine and ill be impressed, John couldnt do that.
Im so glad to see new videos from you. Im a 19 year old student from germany and Im into embedded programming and electronics. Often when i think that something is just to complicated to learn or to program, i come back to your older videos to realize that with enough efford I may be able to achieve exactly what i want or even more. What you've created is incredible...
The only thing that makes things complicated is people who don't really understand what they're doing. If you just start digging and using and growing, eventually your sense of what is intuitive will begin to mirror the world we live in. Don't accept something being "complicated" as an answer. Dig. Because if something is _actually_ is complicated, it means the people who made it didn't understand what they were doing. And you can do better.
@@CNLohr I needed to hear this, about needing to DIG if I don't understand something. Or think it is too complicated. Thank you.
@@CNLohr In most of my drawback in programming is I don't read (or memories) the datasheet(reference) for the language/library/device I wanted to work on, it the most reason why I don't program in C/C++
@@مقاطعمترجمة-ش8ث If you read the datasheets, they start helping you "think" like the designers/authors thought. It is hard to read/process, I know, but that's because it's breaking your brain from the natural way you think, to think in the way that the other engineers think. And it's incredibly valuable to change the way you think.
@@CNLohr amen bro
One day, scientists will learn how to program reality, and some nutcase will try to run DOOM.
I'm trying to design a CPU that works with RISC-V instruction set with a small engineering undergrads team and you came back with RISC-V content. What a coincidence!
You should look at my project. It should give you a pretty good idea of what you really need to make one.
@@CNLohr I will, thanks!
i am literally working on the same project
Clearly your new goal for this CPU is going to have to be to make it run doom, now
@@viviansusername Thats what we all have in mind...
Oh my god
Oh hi Bradley!
Deckard sees you...
RISC-V is so fast and efficient that you're always going forwards, at speeds never known!
*that's* why pressing player back makes you faceplant the wall
This is incredible, looks like magic to me. You emulate processor on a processor to run a video game on it. Just mind beaker.
IKR? It just feels magical when things "come to life" when they become turing complete.
Sometimes I'm very happy to be just an app dev. Most of this just seems like magic to me... xD
Dig deeper, what you learn will always have applicability!
Crocodiles with big mouths, long legs and short arms will be cut down in no time, maybe it will pay off if you start expanding what you know instead of getting stuck.
What @@CNLohr said. If you love programming, you'll LOVE low-level development once you get it. It's often much simpler than high-level frameworks and that stuff.
@@Kniffel101 A lot of low level stuff is just about being obsessed with documentation.
@@0ri3z3r0 I wouldn't say convoluted. But maybe not-obvious, and you're DEF right that there's a huge lack of learning resources. Everyone wants to make a video about some new javascript framework, but no one's excited to explain really deep principles from 1994.
You could achieve a sort of temporal antialiasing by instead of skipping entire swaths of pixels - cycle through which one you're actually using for the ASCII output, to get a sort of temporal dithering. Bayer matrix could spread out the order that pixels are sampled each frame to create the fore/back ground colors for each ASCII, rather than just cycling through them in X and Y. What would be even cooler is if each Doom frame was rendered by a handful of these temporal dither frames - if the ASCII output can be faster than the Doom render, by several frames.
Do I smell an incoming pull request? I don't fully understand what you are suggesting, but the code is available and simple!
This sounds like it would be super flickery, and I don't think there is enough time to anything like stacking frames or doing much in the way of effects.
@@CNLohr I think they are suggesting to write to the terminal so fast that the ASCII characters blend in with each other.
(Imagine reduced opacity on multiple overlayed text characters where lower layers show through)
And all that sorting stuff is probably to get the best combination of characters to layer.
@@iXenox Oh, that makes sense. That would be neat to see.
@@CNLohr Instead of cycling through the input pixels to an ASCII character you could just average all of the pixels' RGB values that contribute to an ASCII character. That would be more stable. There's also room for employing the various box drawing ASCII characters and effectively treating each ASCII character more like two pixels instead of one. Figuring out the optimal way to represent a set of pixels with an ASCII character could be a whole project unto itself! I definitely think averaging the pixels into the output ASCII character is the way to go though. Outright discarding pixels just feels wrong!
I can't even write the most basic of code. This is straight up magic to me.
you can learn
@@CNLohr you can learrn to type ;)
@@c0smo709 thx fixed.
I mean I could argue that SDL, if you just want to push pixels to a window, is so easy that a braindead monkey could do it, and you'd have to be just as lazy as one to be scared by it.
Doom on 512k is very interesting, I was planning on getting Doom or a Doom clone to work on my 65c02 board at some point but I'd have to design a 512k bank switching system and make the memory manager work with bank switching, which sounds like a nightmare, maybe in the future though
hurrfff that would be really hard. And it would be really slow.
ASCII VR renderer next?
With non euclidean graphics
😱
I really don't think it would work well :-/ your eyes would fix on the false-stereo-fusion.
Very impressive. Just out of curiosity - What do you do for a living and how do you get time to do all this amazing stuff?
Impressive debugging, great stuff
Your YT channel is pure gold!👌
Thank you!
"Mom, I want a beautiful 3d render"
"We already have a beautiful 3d render at home"
Beautiful 3d render at home: 8:17
Rocketing forward when pressing back sounds like that one issue with the 'ticcmd_t' struct, which has member variables that are defined as 'char' without an explicit signedness: on platforms where char is unsigned by default, you'll experience that bug. Making the chars explicitly signed fixes the issue.
INTERESTING. I will have to investigate this!!
This video is going to blow up for sure! Great video!
Thanks. I hope! Though it looks like it's already starting to cool down. Didn't really go very far outside youtube.
@@CNLohr try posting on Reddit !
(Also i wanted to recomment changing the thumbnail but you already did, looks better now 😁)
This is exactly my cup of tea!
protip: basically all terminals support 16-color, not only 8 color, even heckin' linux TTY does!
also, you could probably make an optional 256-color mode, which would look a *LOT* better, visually
It would be a lot more text to pipe through the oddball spigot.
@@CNLohr fair at that, although terminal emulators can usually be set to allow pretty fast speeds...also, I've seen people use the half-block characters (one half background color, one half foreground color), is the current way getting more detail, or is that also excess data transmission? it'd need slightly more computation I suppose, but effectively give a canvas of pixels, twice the height and same width as you'd fit with normal characters (with square pixels!)
My favorite tools, valgrinned and lie basan. Seriously though, very cool
this is awesome Teletext Gaming
Thanks for the content. Keep it up.
We'll see how long I can keep the momentum going.
You actually did it, absolute Madman
I want to Rephrase it from "can it run doom" to "how long till it runs doom"
Your comment did make the video!
Now i am intrigued what performance would be if we used an RP2040 with some external serial RAM and VT100 emulation video output on VGA.
Would the system still be usable as a tiny cheap Linux PC or not?
EDIT: Defining usable, snappy enough that some editor like Tilde and tools like Midnight are not laggy to use, my benchmark would be some XT class machine running MSDOS with the QuickIDE and Norton Commander. Stuff takes some time to load but when up is snappy to use.
there is esp32 ports... so I dont see why not
I agree, it should work.
I'd be curious to know what drives you into creating mind blowing side projects like this. Taking on a challenge, flexing, pure curiosity, excuse for not working on some even more complex project, just a way to relax or something else? Regardless of the motivator, so much fun even if 97% goes over my head.
I love to teach and inspire and see what people do as they get tools in their hands that they never knew existed.
Best answer!
It's where the brain goes when it's trying to avoid doing real work.
Doom Guy's eyes had me laughing. Look so hilarious in a terminal.
I know a colleague at uni, that ported DOOM to RISC-V for a demo of our RISC-V CPU.
I now feel stupid, for not asking him in time to upload the code to the uni repos.
Your version in the terminal runs much faster btw.
But our code was also largely unoptimized (I suggested making use of our extensions, as we were using an FPGA with a bunch of custom peripherals, but he was like: "Nah, this is more or less the original DOOM. Using our PPU for the color palette and our extensions would be cheating").
But yeah, our 50MHz RISC-V CPU running on an FPGA runs DOOM in a playable manner, as well.
Always funny to see other people doing the same stuff.
My emulated CPU is only around 200MHz on my laptop, so it shouldn't be _that_ much faster.
Could that problem you describe at the end be a similar issue with signed/unsigned integers? Like, changing the position by x when moving forward, and x times -1 when moving backwards?
That is possible. Though I have not debugged it yet.
What's the font we see when you're looking at the makefile at 6:40? It looks so much better than what I'm using at the moment.
Yes, I realise the video is about your work on doom for your emulator, and it's amazing what you've achieved, but that font looks fab.
audiolink.dev/
i have a feeling that soon doom is gonna run on ANYTHING WITH A SCREEN
Or without.
Good video man!!!
Great to see you back and apparently doing well.
Hey, congrats on getting Doom to work,
Thanks!
Really smooth
My god this channel is a treasure trove
I tryyy
i want a doom deep dive!! doom code is always great to hear about
I am not sure if I'd want to focus more on doom or the work I've done to be able to cram it into mini cupcake of an executable.
@@CNLohr why not both!
If you really want a DOOM deep dive, check out Fabrice Sanglard's Game Engine Black Book for it.
I had the same bug launching the player forward on pressing backwards on a Raspberry Pi with my doom port! It's simply to do with Doom assuming a char is signed in the ticcmd_t struct in d_ticcmd.h. I fixed it by explicitly changing "char" to "signed char" haha
Yes, yes it can
Impressive
Thank you. But the real magic is in the Carmack Code.
Cool! ❤️
You can emulate A extension if code runs in Machine mode and interrupts are disabled. In lower privilege modes atomicity can't be guarantied because of M mode interrupts
Interesting point. I hadn't considered that. Are you pointing out that the atomicity of the load/store semantics will cause an issue if I am not properly emulating the memory slot? Do you mind opening a new github issue for this and explaining?
@@CNLohr not quite, i send you PR
This is so cool
Very cool 👏🏽👏🏽
thanks
I missed your videos!!, what font are you using on your console and editor?
audiolink.dev/
Turing completeness fan vs can-it-run-Doom-ness enjoyer
I think they are one in the same.
There's a whole library dedicated to generaring optimal ASCII patterns out of pixel graphics, its called aalib. You should try using it. There's also a very cool demo using it called BB
I have thought about using it, but it's all so much more complicated than the naive approach.
@@CNLohr I never used it but I was under the impression that it just takes a pointer to a framebuffer and outputs the characters so it would be perfect for this. In fact you can already run doom on aalib in a way, because SDL supports it as a video driver, so chocolate doom using SDL can run in a terminal using aalib. Great channel btw, ive watched a bunch of your videos recently :)
Im waiting for people to run doom on a breadboard at this point
I feel like Ben Eater might have just been zapped in the back of his head.
Needs a Teletext version for Prestel terminals.
Sounds like a PR you should make!
@@CNLohr
This also reminds me of the world cup ASCII telnet server from 2006.
I don't know the Doom source code, which file contains your code for choosing the characters and letters for a given block of pixels?
dude, you rule
Completely off topic, but which font are you using for your terminal emulator?
AudioLink Console audiolink.dev
"Okay, but can it run RISC-V?"
I'm sure the internet is on it.
@@CNLohr true, true.
Now I need an executable for my soldering iron.
I still haven't done anything to support other screen sizes
@@CNLohr I was joking. But it would be better than Tetris.
Has anyone found a way to run Doom on one of those digital fireplaces? Just think of all the romantic nights everyone will have!
Are any of them controlled with individually addressable LEDs?
Someday, I will put Doom on the Model2 arcade board. Intel 80960 Doom just sounds fun!
And quirky.
most terminals support sixel as a graphics mode, libsixel might be a good method to get a 320x200 postage stamp.
If you're interested, you could totes make a PR.
where should I start looking to find where it makes graphics into ascii?
i don't speak Q-Bit, but. i enjoyed the doom interpretive art. i wonder now, how detailed can you make dwarf fortress, doom fotress, i mean asci doom.
So, now that you have it running in text mode, and without MMU, would it be possible to make this DooM run on a pre MMU capable x86 such as the i80286 or even 8086? I think the entire retro community has been waiting for that for a long time! Please say yes!
It would just be uncomfortably unplayable. That and DOOM isn't exactly the smallest footprint, memory wise.
I noticed that you added your font to the description, but Google didn't turn up any links relevant to it, do you have a link for where I find it?
audiolink.dev/
@@CNLohr thanks!
Is there anyway to get AudioLink Mono Heavy font without installing AudioLink software?
audiolink.dev/
I searched for the font family "AudioLink Mono Heavy" on the internet, but I didn't found. Someone can help me to find this amazing terminal font?
audiolink.dev
@@CNLohr Thank you so much! I really liked these fonts! ❤
@@thiagofalencar llealloo is the author, not me!!
Next: RISC-y Apple
You're a god!
RISC-V can work with digital audio processing ?
It can. Though that matters more about the specific silicon surrounding the core.
nice :)
Next: Running Doom inside Doom
🤤
Or you can get the 8BitGuy to do Pescii Robots on it
What font is this? Beautiful
audiolink.dev/
You should make a video on how to learn shaders in VRChat. I'm a computer science student and I really want to experiment with shaders [already been building with avatars/worlds] but I can't find any good resources on how to get started with shaders. I'm sure a lot of people would appreciate this from someone with your level of experience.
I have thought about this a lot. And talked to others in the community. But I haven't had the "hook" to make it happen. It's a lot of work to make videos, and unless I'm relatively confident they'll get a lot of views it's hard to make them.
If you want to make it look much better, use any 16 color wad as Doom palette is too oscure, and avoid using any text characters, half block characters are way better
Someone's already added support for 256-color terminals.
Im doing my big boy riscv64gc mmu emulator for 2 years. Right now putting jit into it. It's very cool that you can boot linux without mmu
I am curious what kind of performance factor you see.
@@CNLohr it's interpreter, but with basic block caching (so I didn't parse instruction every time) and mmu caching(tlb's), so performance varies a lot when linux starts to flush caches.
Best case is softpipe rendering glgears 100 million instructions per second, but it drops to 20mips on systemd startup.
Also, I my rootfs is nfs, for ease of development
@@CNLohr also, it depends on how close to so spec you wanted to be.
For example: every target of branch instructions should be 4 bytes aligned (2 bytes if C-ext supported)
awesome!!!
Or maybe a class C amp. Never got a chance to try it though.
it now runs doom, but will it run skyrim?
or crysis?
7:34 oh god that's the worst. I immediately thought "oh, a different language would catch that" but would it? u32s can always be implicitly cast to i64s because an i64 can hold every possible u32 value-so no, it wouldn't. I guess one thing that could prevent that from being an issue is storing registers as as a union{u32, i32} instead, that way you have to select one each time. especially since so many riscv instructions are signed only or support signed ints. not sure though.
Porting doom to TF2 would be pretty funny x3
It may or may not happen. Not sure.
But can it run Crysis?
Your content is soooo good. Please please make a tutorial on how to write a RISCV emulator in C. Surprisingly, there's no good video tutorial on it
I put a link to the source code so you can look yourself. I tried to make it basic and document it.
2:27 this works with python on windows too
yes it does
Tons of errors in that compile, man... Did you lint that code?
I play it fast and loose.
its a feature
I understood some of the words you said
google is your friend. My goal in my videos is to send you down rabbit holes and to get you to start learning!
This is just 1337doom with extra steps, lol
I suppose so.
oooh, emDOOM looks really interesting. but the 5MB WAD file seems like a major bottleneck for most if not all Microcontrollers (what low to mid tier MCUs have >5MB of flash?) and Von Neumann based DIY systems (68k, 65c816, Z80-ish, etc) where Program and Data share the same memory.
i wonder how small the WAD would be if you cut everything except the first episode, or even just everything except E1M1 and all required graphics for it.
It would likely be a lot better sized, and if you shrunk down things like the boot screen, etc. I think it would help.
@@CNLohr i grabbed the full Ultimate DOOM IWAD and used SLADE to remove all music and sound effects, all levels except for episode 1, and all unused graphics. the total file size is down from 11MB to 7MB. (where did you get 5MB mentioned in the github from?)
the main bulk are the graphics (~6.1MB). reducing all of them from 256 to 2 colors would cut the size down a huge amount...
but then the game would be completely monochrome.
so maybe halfing the resolution and going from 256 colors to 16 would be a better idea. in theory it should have the same decrease in file size as going monochrome.
or maybe some basic file IO would be better to not have to load all levels and graphics into RAM at the same time
try plane-ray intersection culling with sphere entity volumes (another type of bsp tree, more general hierarchical volumes tree) instead of normal doom render method
its real 3d, not 2.5d, even if rendering vertical lines (the plane-ray of a vertical line of the monitor), more like quake but feels like doom/duke3d, its a specific case of a ray-caster
manipulate the fonts on the fly per frame, to print the correct character pixels
ie dynamic font bitmapping
meh its a text mode pixel manipulation, only limit is how many character fonts you can have at one time, or just draw one text box at a time, then draw it, draw next, if you cannot access pixels directly
fonts are pixels, bitmaps, ready to be blitted, right
everything can run doom
google charles babbage's difference engine
@@CNLohr what
Man can it run Bad Apple!!
Maybe sometime.
Cool!
Is that a port of Doom for RISC-V?
yes
for how long you've been coding tho? i mean your XP 🤔🤔
Almost 30 years.
Next up: but can it run Crysis?
Make it open source.
Heh, this reminds me, when I used to draw graphics in Pascals by writing to B800:0000 (or what was the magic number) with ascii. Easy to do Tetris, Sokoban, or Snake. Really nice job with the emulator and bughunting.
Depends on the video mode. 0xA000:0000 or somewhere in the B's.
Yup! Or, I grew up with an 8086 with built-in 128k EGA. You can write to all of 0xA000:0 to 0xB000:FFFF, 640x350 at 16 colors, two pages. What luxury!
Or should I say &HA000 because I was mostly poking around in QBASIC at the time (yuck!). Oh but it was so weird, with the bitplanes. Took me a while to find out you need to talk to the graphics registers too, to draw any colors.
@@CNLohr yeh, I think it was the 80x?? mode? I remember having to switch. Ive just checked B800 is really the magic memory address in pascal. Im probably just remembering 16bit version. So just B800.
3:02 Ah, back to BASICs. Screw OpenGL, we're poking now.
bingo :figerguns:
wow
cannon player XD
But can it run Crysis? 🤔
Unless it can run Doom, it's a bad system
Why is everyone so interested in RISC-V lately? I've barely even heard of it until recently, and I figured that ARM was the superior RISC architecture anyway. What's so special about RISC-V?
It's that the ISA, spec, toolchains are all open source. So if you want to work on a RISC-V you don't have to learn absurdly specific and proprietary stuff just to use the base CPU.
Is this some kind of dyslexia-friendly font? If it's just a stylistic choice, it certainly is unusual.
It's just AudioLink Console audiolink.dev
@@CNLohr don't take this the wrong way, but I would shoot myself if this was the only terminal font available. Or switch jobs I guess
The font is obviously no barrier to you, I was just curious if it's a necessity
but can it run bad apple?
Maybe some day.
I know some of these words.
Google is your friend! My goal in my videos is to send you down rabbit holes and to get you to start learning!