-
Content count
10648 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
News
Everything posted by fraggle
-
No, it isn't. Go and read the post you quoted, and then read it again, and then read it again because it makes a lot of really good points. NIH took the time to give you some detailed (and good) advice and you really should read it and pay attention to what it says.
-
"A Secret is Revealed" message not appearing in PRBoom+
fraggle replied to AtticTelephone's topic in Source Ports
Multiple source ports have all independently added the same feature and implemented it in basically the same way, which I think is part of why so many people have forgotten it wasn't in the original game. In fact, even the official 2002 GBA port of Doom II added it. I even had a bug report because Chocolate Doom wasn't showing the message; it's one of my favorite bug reports. -
Does it appear in chrome://apps/ ?
-
That C64 video is an obvious fake. You're not going to run Doom on a C64.
-
What programming language do you recommend for a newbie?
fraggle replied to DooM Bear's topic in Everything Else
Another vote for Python. -
New source port: Altair (SDL with OpenGL backend, Boom stuff, and more)
fraggle replied to Redneckerz's topic in Source Ports
I've filed a bug about this. Probably it's just an innocent mistake - most people just don't know about all the intricacies of software licensing. -
Has anyone ever tried contacting/interviewing the Doom comic authors?
fraggle replied to lazygecko's topic in Doom General
I asked @thatsbelievable some questions back in January 2018. I don't have a Twitter any more (deleted my account) but here are the tweets for posterity: -
What do you think of the C-family programming languages?
fraggle replied to Cacodemon345's topic in Everything Else
I've come to really like Go, which I place in the same family. Its main feature is its lack of features, which sounds counterintuitive until you actually spend time using it and find that it's a deeply liberating experience to be able to just focus on solving the problem at hand rather than have to deal with boilerplate and arcane details of the language you're trying to code in, which is the usual experience with a lot of languages. The feature set it does have is a thoughtfully chosen and powerful one, and it avoids the mistakes of past languages, especially OOP languages. Contrary to what Graf says it is entirely possible to do OO with Go; in fact, the language encourages good practices in OOP rather than stuff like inheritance which a lot of OOP people are nowadays seeing as a mistake. Go's interfaces are a simple but wonderfully powerful feature that I'm missing now that I'm having to write C++ in my day job. Everyone learning Go tends to go through the same reaction of "it's a nice language but I wish it just had this one feature...". Whatever it is for you, you just have to make peace with it, and once you really get into it, you'll probably find it's not such a big deal. The language has been thoughtfully designed with a view to making the day-to-day experience of programming pleasant, and it really shows. -
Maybe someone can substitute in some of the Freedoom assets.
-
Am I the most hated member on Doomworld forum?
fraggle replied to Can't play on Nightmare's topic in Everything Else
No. -
You certainly don't need the sprites and other graphics. Note that your WAD will be rejected from idgames if you don't fix this.
-
Who is good enough at Doom to finish Sunder?
fraggle replied to Can't play on Nightmare's topic in Doom General
Every post you make here seems to be some variant on "X is too difficult to me to play". We've all got the message and it's becoming increasingly tedious to hear you repeating it day-in, day-out for what's now been months. Can you please find something else to talk about? -
Hey, your WAD for some reason contains a huge number of unmodified copies of the IWAD resources (sprites and textures). I suggest you remove them.
-
(NON-SOURCEPORT DOOM) is it possible to bind next/prev weapon keys?
fraggle replied to ChileanDoomer's topic in Doom General
Nope. What's in the setup tool is all you see. Chocolate Doom has prev/next though. -
DEHEXTRA discussion (split from Pr+ UMAPINFO thread)
fraggle replied to Altazimuth's topic in Source Ports
Before we start considering forks, I'll just say that I'd be open to including this in DEH9000. I'd like to see DEH9000's state parser expanded to something like a DECORATE-lite so that people can write vanilla-compatible patches (Or Boom/MBF-compatible, etc.) in a nicer format while being able to take advantage of DEH9000's features like the state auto-reclaim. It's potentially tricky in some ways though and parts of it need to be carefully considered. -
My interpretation was that he was referring to how the i_video.c code in the original linuxdoom sources only works if your X server is running in 8-bit color mode, which is obviously an anachronism today. That was actually one of the original motivations when I started Choco - I wanted to be able to run the linuxdoom source because even back in 2005 you couldn't easily run it on modern Linux systems any more.
-
My suggestion would be to look at the early beta versions of Chocolate Doom (v0.0.1 - v0.0.4). Here's v0.0.1 for example and here are all the changes that were made to the codebase up to that point. It's only 83 commits so in theory you could cherrypick just the minimal set of bits you want.
-
It's unclear what you're asking for. Chocolate Doom meets the criteria of "very simple doom source port with nothing changed". It sounds like maybe what you're really asking for is something as close to the original linuxdoom sources as possible?
-
Should Doom 64 get its own category in the forums?
fraggle replied to AtticTelephone's topic in Console Doom
I don't think there are enough threads about it for it to be worth it. Even this forum (Console Doom) doesn't get that many threads. -
Yeah, the Doom assets are low enough resolution that even individual pixels in a texture can be significant detail; see the corridor wall close-up from my album for example, where there are single pixel rivets that just get smeared out by the filter. The problem as I see it is not that any kind of filtering is inherently a bad idea, but rather the GZDoom default approach of just chucking the Doom textures and sprites into the usual GL linear/bilinear/trilinear filter is a naive one. I'd just like to see a bit more care put into the defaults; the current ones come across as thoughtless.
-
I have to admit I'm mildly tickled to see that term being applied to GZDoom. There are at least some good reasons to turn on texture filtering by default (moire effects etc.). That said, I'm kind of surprised GZDoom hasn't changed its defaults to use eg. Normal2x upscaling; it seems like that would be a reasonable compromise that would allow it to keep filtering while addressing the "smeared vaseline" look that everyone always (understandably) complains about. The only downside is that it uses more texture memory but I presume any modern machine should be able to handle it fine. EDIT: Made a gallery on Imgur to show what I mean.
-
xda46 said to me in a PM: Basically there are two ways that flash memory can be accessed by a processor. If you think about how a USB flash drive is connected for example, there's an overhead to read anything from it because you have to send a USB request to the device to fetch the data. It's a similar situation with things like SSDs. The second way is that the flash memory may be connected directly to the CPU's bus. In that case there's no difference between reading something from flash memory and reading from RAM - it's fast and always available. It sounds like that's the setup you have, which helps. Sometimes when you have an embedded operating system, it provides a filesystem interface that's backed by the flash memory. That's why I mentioned mmap(), since it means you can avoid wasting RAM just to access the contents of the flash memory (Doom's WAD & zone memory system usually does this). In your case you don't have a filesystem though so it's a moot point. The easiest way for you to proceed is probably to embed the shareware WAD file inside your program. Boom's UTILSRC for example has a program called BIN2C that will convert a file into a C source file containing a huge byte array. Then you might want to take a look at Chocolate Doom's memio.c which contains drop-in replacements for the standard C file functions. That should allow you get the WAD code working without an underlying filesystem - just reading stuff out of the big byte array. See if you can get the initialization code up to the point where it's running R_Init() successfully - if you can, that should be a big milestone. I'm obviously biased but you might find things easier if you start with Chocolate Doom as the codebase since I've already made all the changes needed to support memory-mapped I/O, which you'll probably find helpful later. There are also portability issues you can run into with the original linuxdoom source that id released. Another suggestion is that you might want to try using miniwad.wad as your IWAD initially since it will use much less RAM and Flash space.
-
letters.wad is a level containing a hallway of words made entirely out of cut-ups of the UAC logo from SHAWN1. The WAD contains no custom textures. The WAD file is entirely generated by a Python script that constructs all the linedefs with just the right lengths and X offsets. Only certain words can be generated with this technique because I've only been able to generate certain letters. For example it's possible to make 'L' and 'J' from the two sides of the 'U' in the logo, but it's not possible to make "N" or "S". The source code is here: https://github.com/fragglet/uacletters The contents of the WAD are free to use, so if you'd like to use this to write "LOL" on the wall of one of your levels feel free to copy/paste. An earlier version of the WAD got posted to doom_txt and some of the reactions are pretty funny:
-
There's a posting limit for new users to prevent abuse - I think it goes away after the first day. 7MB of flash is tighter than I expected. I assume this is built into the chip? However, that's more than enough space to fit the Doom executable and the shareware WAD (which is ~4MB). The zone memory system is essentially Doom's implementation of a virtual memory system that caches data on disk and brings things in and out of memory as they're needed. There's a page about it on the wiki and I can also recommend reading the Doom Engine Black Book which is a great resource on the Doom engine: check out chapters 5.7 and 5.8. To try to clarify: normally when Doom uses something from a WAD file, it allocates some memory, reads the lump into that memory and then releases the memory when it's finished. In your case that's pointless since the WAD file will be in memory (flash memory) from the start anyway. That should be relatively simple to do and will save you a lot of memory, since usually, the majority of all Doom's memory allocations are just caching stuff read from disk.
-
I'm more optimistic than others here about your prospects since you have underlying flash memory. Doom's WAD cache and zone memory system was implemented with the assumption that the underlying storage system was slow (ie. hard disk) but that isn't the case nowadays with flash memory and SSDs. You can be as aggressive as you want about moving stuff in and out of RAM from flash and it shouldn't really matter much. One thing to look into is whether the flash is memory-mapped. If you can access the data in flash directly just like it's RAM then you can bypass the caching entirely. Making a broad assumption about your choice of target device, I'm guessing it probably is memory mapped (otherwise you end up wasting RAM just to execute code, which is wasteful on embedded devices). Chocolate Doom supports this for example through the POSIX mmap API (w_wad.c; w_file_posix.c); I just checked and it seemed to run fine with a 1MB zone heap. I wouldn't be surprised if it can scale down smaller. If you can make the caching part a non-issue the limiting factor then becomes stuff like the data structures that represent the level and its contents. I'd probably recommend instrumenting the zone memory code so that you can figure out what takes up the most space. At the very least dump some details about all the zone memory blocks whenever you run out of memory. EDIT: Managed to scale down Choco's heap to 650KB before MAP01 wouldn't load any more. But this is with a 64-bit compile; things would be marginally more efficient on a 32-bit machine where all the pointers are half the size.