Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

wesleyjohnson

Members
  • Content count

    1428
  • Joined

  • Last visited

7 Followers

About wesleyjohnson

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I run 32-bit Slackware Linux too. I agree, there is no pressing need now for 64-bit addressing either. As to that other forum: I am putting this here because I don't bother with those people anymore. I won't even reply to them anymore, cause it is not worth the effort. They will get upset if you won't do the same as they are doing, or dedicate your priorities to using the system they favor. It is all emotional arguing, insults, lies, and opinions passed off as fake data. They push what they do as "everybody is doing it", and then declare anything else as "dead" to try to take away any other options. There is nothing to be gained because such people will NEVER admit to anything counter to any opinion they hold. They are not worth the 7 sentences already invested in this. I agree, there is no problem with compiling 32-bit packages. I compile much of the important packages anyway because I can specify the CPU as K10 (Athlon64), instead of having to settle for i586 code, or i686 code. The binary packages that can be downloaded are so generic that they don't use the CPU capabilities that we have invested money and effort to obtain. Don't have to do anything special in compiling the packages, other than to specify the CPU properly in slackbuild. I make a copy of slackbuild and modify it, adding K10 options to the CPU menu. I could use the "native" setting, but that makes it difficult to properly label the resultant binary. The slackbuild binaries are marked as to i686, or K10. How much trust can I put into a native CPU compiled binary a few years from now, when I may not remember which machine it was compiled upon. So I go through the extra trouble of adding options to the CPU choices in every slackbuild. The compiler will detect situations where it can use the advanced instructions, use them automatically, and do it better than most of SIMD code I have seen. I worked on some of the Flightgear SIMD code, due to it crashing on 32-bit systems. Flightgear has explicit SIMD support in their SimGear package (various different kinds of SIMD support). Trouble is, the SIMD support was ineffective. When I disabled the SIMD support it ran faster. The problem was that they did not realize that SIMD instructions require the data to be in the SIMD registers, and that to use a single FAST SIMD instruction to add 3 components of a vector requires the compiler to move those components from from the regular registers to the SIMD registers first, and then move the result back to the regular registers. The extra overhead totally wiped out any gains. Saving cache space, avoiding fetches to main memory, has been proven to be more important than clock speed. If your pointers are smaller, your cache usage is more efficient. Using an estimate that pointers account for approx. 20% of data structures, then using 32-bit gives me about 10% more cache space. Even a gain of 10% cache space is significant due to avoiding the reloads for two conflicting memory accesses. Speed gains can exceed 20% due to the reduced size of conflicting addresses that remain. I have been changing some of the DoomLegacy code to take better advantage of the number of instructions that can be executed during a main memory fetch. Probably can afford to use 5 or 6 simple instructions, if it will save a main memory access. Some of the Doom code has had tables to avoid some calculations. Fetching those from main memory is no longer cost effective. Even 1/x can be calculated in one clock. Large lookup tables are no longer a great speedup, and they use up valuable cache space. If the same result can be calculated in 5 or 6 instructions, it will probably be faster than using the table lookup. Will have to put in some timing test to verify exactly what the speed trade-off is before just changing stuff blindly on suspicion. Been squashing some of the data structures too to reduce the cache footprint (thus speeding up everything). Many structures used an int as a default numerical type. If there are many copies of that structure in memory, then there can be significant savings in your cache footprint by changing to an int16_t or even an int8_t, where possible. I have found that it is not that difficult to align structure fields manually. Putting all the pointers in a structure together makes it easier to make then aligned (aids with memory fetches that do not have to cross cache lines). Have moved some of the structure members around so the pointers are at 4 byte offsets. Having fields grouped in a structure according to function never did work that well anyway, so grouping them by data size, so the field alignment is maintained naturally, works out fairly effectively, and is perfectly readable too. Most attempts to use the PACKED attributes, to keep holes out of structures, has had a host of problems. DoomLegacy is supporting compilation on 4 to 7 different compilers. It would be easier to go GNU GCC only, but for years we already been supporting other compilers. I already have GCC-4, GCC-10, Clang, MINGW, and WATCOM support, and if I remember all the rules, it won't break. Have not been able to use any PACKED attributes because tests on MINGW indicates that it totally ignores all the variations that I have tried. A supporter has submitted some code that includes among other things a system for defining a PACKED macro, that seems to work for a number of compilers. I have to see what the response is from those who compile on BSD, FreeDOS, and others, before I can recommend it. Been working on some of the DoomLegacy OpenGL code the last few days. Looks like a bug breeding ground. Trouble is, every time I try to fix one of the more ingrained imaginative data structures, it often breeds a entirely novel new bug. Made the OpenGL renderer use the new extended skies (changable in the menu). Looks nice. Only problem is that after 4 or 5 sky changes, strange things happen, random texture changes, like the player weapon changing to a floor texture. Changing a texture after it is loaded into OpenGL has not been provided for in this implementation. Attempting to do so leads to corruption of a texture list maintained by the OpenGL driver in DoomLegacy. It seemed like a simple fix when I started working on it, and now I have to extend the OpenGL support too.
  2. wesleyjohnson

    Accessibility in source ports

    Idea: visual sound directional oval Each monster type would have a sound icon. Words are too slow to read, you need a shape. The shape that corresponds to a monster can be learned, just like a sound. You know the spider-demon does not go around saying "Spider-Demon" as its sound. It is a sound you have to learn to associate with a Spider-Demon. This could be a stylized monster shaped icon, or it could be selectable from geometric shapes. Common sounds would have simple common icons, the simpler the better. A shot would be just a little bar. The visual sound would be displayed on a directional oval, just above the status bar. A monster to the right would have the sound icon displayed to right (the right of the oval). A monster sound from behind, would be displayed just above the status bar (the bottom of the oval). A monster sound from ahead, would be displayed higher, centered (the top of the oval). Louder sounds would be displayed brighter, while faint sounds would be barely visible.
  3. wesleyjohnson

    Accessibility in source ports

    I had to write a tool that would be used by a color-blind co-worker. Changing the colors was not necessary. It was adequate that the colors could be distinguished in spite of not being able to distinguish red from green. I tried several color changes, but decided on making the visual indication in two modes, using both color and symbol, so as to not degrade the other workers ability to use the tool. Boxes were not just green or red, the green was bright, but the red was only medium brightness. The ON box had a green dot (like a lamp), while the OFF box was empty. I had tried another symbol, like an X for OFF, but he found that confusing. Some toolsets of that time used an X as a check mark. If I remember right, a red X (with wide bars) was used as an error indication. Other symbols like a red box, were not distinctive enough for an error indication, there had to be a symbol.
  4. wesleyjohnson

    Accessibility in source ports

    I considered such issues about a year ago, and put some "features" into DoomLegacy. - slow doors setting, which makes doors stay open longer - can turn off screen flash on object pickup, the status bar has a small box that blinks instead. - has support for joystick, with many buttons, all mapped in the control menu. - has support for xbox style controller, all buttons and joys are mapped in the control menu. - can play without keyboard, using joystick or controller to control menus. Cannot type savegame names, or port addresses though. I considered adding a visual sound indication. This would indicate sound direction visually, at the edges of the screen. The difficulty would be sound volume and not intruding too much visual noise into the playing area. The current visual damage indication gives only very slight directional information (player is moved by being hit, which is better directional indication than sound).
  5. wesleyjohnson

    OG Xbox Doom legacy

    This is from the DoomLegacy docs, legacy.html. If you do not have a keyboard, then you cannot drop down the console. As console is keyboard input anyway, that is appropriate. If you have a keyboard, then you can change what key drops down the console. It is in the menus, under options, controls. I use "ScrollLock" for my console key. but I think the default is the accent (next to the '1' key). Looking up Xbox emulation, I found emulators for the Xbox on the PC. That does not sound like what this is talking about. "OG Xbox backwards compatibility mode, emulation" is meaningless to someone who does not have an Xbox manual. I did by luck find out that XBox is a Microsoft product, therefor if it emulates anything, it is going to be some version of Windows (could be WinXP for all I know). The quality of my answers to questions will be limited by the vague-ness of the information fed to me. There are two major DoomLegacy ports, the SDL Linux, and the SDL Windows, and a bunch of others and derivatives. It does make a difference for some questions.
  6. wesleyjohnson

    OG Xbox Doom legacy

    "again this is Doom legacy port for the original Xbox, ran on my modded 360 not xbla or anything like that. " As there is no port for the Xbox 360, then either it is running Windows, or running Linux, or someone has compiled the DoomLegacy source code for the XBox 360, in which case it is entirely up to how good the libraries are at matching the originals. Someone (I forget names) submitted code that allowed xbox controllers to be used, without having a keyboard. (That code is in 1.48.8, but not in 1.42.) He may have been running it on an xbox too, or just using the controllers. The added code allows an xbox controller, without a keyboard, to set options and work the menus. I don't see how they type in a decent command line, or work the console.
  7. wesleyjohnson

    OG Xbox Doom legacy

    As other replies have stated, "-file" loads PWADs. These command line options have been inherited from parent sources, and are common with most Doom ports. Before you search all over the web, look at the official DoomLegacy sites. There is a separate docs and support package that you need to download from the sourceforge site. Many people seem to miss that. There are installation instructions in the docs folder. DoomLegacy_1.48.8_common.zip Download site https://sourceforge.net/projects/doomlegacy/ DoomLegacy Home page DoomLegacy Home User Reference Manual Every DoomLegacy has come with a User Reference Manual in the docs folder of the installation. To load a PWAD (Version 1.44 ... ) >> doomlegacy -game doom2 -file cavern.wad >> doomlegacy --help >> doomlegacy -h g May 18 2021 Doom Legacy 1.48.9 (rev 1579) 22:10:53 -game name doomu, doom2, tnt, plutonia, freedoom, heretic, chex1, etc. -iwad file The game wad -file file Load DEH and PWAD files (one or more) -deh file Load DEH files (one or more) -loadgame num Load savegame num -episode 2 Goto episode 2, level 1 -skill 3 Skill 1 to 5 -warp 13 Goto map13 -warp 1 3 Goto episode 1 level 3 -nomonsters No monsters -respawn Monsters respawn after killed -coopmonsters Monsters cooperate -infight Monsters fight each other -fast Monsters are fast -predicting Monsters aim better -turbo num Player speed %, 10 to 255 After starting DoomLegacy, you can drop down the console and type. > MAP CAVERN.WAD and this will load that wad and run it. I don't know which version you have, or which port (Windows, SDL, etc.) you are running on a "360". I never ran game systems so "360" means to me an IBM 360 mainframe, and that can't be right. If you are getting binary from some third party, they often do not make complete packages. Wesley Johnson, DoomLegacy Team
  8. wesleyjohnson

    Posssible OOB read in R_DrawColumn()?

    The original draw routines are known to have limitations. Using them to draw things that do not meet the original assumptions leads to buggy behavior. However, the routine that calls the column_draw could be blamed, or not having a column_draw specific for the usage could be blamed, or the wad could be blamed for trying to draw with a small texture. The "&127" in the column draw supports tiling the texture over a large wall. It assumes that the texture is 128 high. The tiling does not work on textures that are not 128 high. Trying to use the column draw on a smaller texture, and allowing the draw to wrap, will result in drawing garbage. This is the result of not restricting the texture draw to an appropriately small area. I have rewritten those routines several times in DoomLegacy. The whole issue is complicated and highly dependent on exactly how your port is going to deal with the odd sized draws. I must refer you to the draw code in DoomLegacy and similar advanced ports. In DoomLegacy, within the last year, I reworked the column draws to support DeepSea patches. It also fixed some outstanding issues with the column draws being misused. This required explicit support for the non-tiling draws in the texture draw function structure. I cannot remember enough details to even describe it well.
  9. wesleyjohnson

    ALSA MIDI

    I am only going to share this, for the amusement of any programmers out there. It is about how much trouble a little "Hack" can cause. The Linux X11 port of DoomLegacy was getting the sound worked over, because it was still using OSS sound interface, and my Linux distribution does not enable that by default. I decided it was time to update it to ALSA, and perhaps a few other sound drivers. The sound effects sound had already had a similar selection feature for some time, allowing selection between OSS, ALSA, ESD, PULSEAUDIO. and JACK. If multiple sound drivers are specified at compile-time, it will generate a menu entry for selecting between the devices for playing sounds. I did not want the sound devices to suddenly be switching on and off when the user was scrolling through the menu selections. I implemented a "Hack" where a sound config variable change would send an invalid value to the sound player, to tun it off. After a delay, it would send the code for the new device to the sound player. While the user was scrolling through the menu selections, the delay would keep being reset, so only the final value would get sent to the sound player. This would implement a nice clean mute while the user was flipping though sound device selections. This was implemented in the sound system, which was a mistake. It worked fine, so when it came time to work on the music player, it got the same mechanism. It got a menu for selecting between multiple music playing devices. ALSA is not well documented, so it is a matter of experimentation as to what each of the many library calls actually does. I got instrumentation all over the place. One thing I am watching is the the current music tick, and the ALSA queue tick. These are the music "time", where it is in the music playback. I had got into looking at the queue tick in an effort to throttle the playback, so to not saturate the ALSA queue, and to make it more responsive to DoomLegacy changes. The responsiveness problem is likely to go away, as other ways to deal with that are being worked. During testing, the music would start playing and then suddenly stop, and then start playing again. The instrumentation on the ALSA queue showed that the ALSA queue tick time was being reset to 0. When that happened, all the MIDI notes in the ALSA queue would just stay there until the ALSA queue timer had got back to the time when they were scheduled to be played. There would be silence while the timer slowly worked its way back to where it was, and then it would pick up playing where it left off. Now, I got ALSA experimental hacks all over the code, trying to figure out how to use it without proper function documentation. I am testing everything that looks suspicious. To shorten this narrative a little, it was not the ALSA code, it was that "Hack". In DoomLegacy, the config variables have an extensive system for the user to change them, and for their values to be saved in a config file. At startup the config variables get set, and then the sound system is initialized. The initialization of the sound player had been carefully crafted to deal with the config file loading. A second setting of the sound config variables was expected, and it was arranged for this to properly setup the sound player. The "Hack" was catching the change to the sound config (from loading the config file). It then issued an "off" selection, that got overridden by the initialization of the sound player. The sound player would startup, initialized itself, got the intro music song, and would be playing. The delayed sound device setup call from the "Hack" would then occur. The sound device change code of the player was one place that was not instrumented, because problems were not occurring there. The one thing it did that was noticed was to initialize the ALSA queue, which set its timer to 0. The rest is just details. The mechanism for putting a "MUTE" duing menu flipping has been moved out of the sound system, into the menu system, where it no longer gets triggered by config file loading. The music playing using ALSA is much better now. A little tuning of that responsiveness has to be done, like taking out half of that code as unnecessary. If you read this far, then Thank You.
  10. wesleyjohnson

    Preferable CO-OP Source Port?

    With a question like "What is the best port for ...", you know that everyone is just going to list their favorite ports, based on their own favorite reasons. Now, if you list some requirements, and features, that might restrict them a little. DoomLegacy Coop features. - Designed for multiple players. - Designed for network play. - Supports Coop play Can select altered Coop play. This was added because some maps having unusually difficult monster selections for coop play. Coop options: 1. Coop weapons, Coop monsters 2. Use Coop weapons, otherwise the Single Player map. 3. Coop with boss monsters reduced to 80%. 4. Coop with boss monsters reduced to 60% The last two will change a CyberDemon to something more normal, like a Hell-Knight. Many maps will throw in CyberDemons on Coop play, like there will be a gang of expert players to attack it. This does not work out well when Coop is being used when some of the players are weaker. These Coop features allow you to play a normal map with multiple players, without the unreasonable difficulty.
  11. wesleyjohnson

    ALSA MIDI

    This question is for any Linux programmers, who may have happened to played MIDI through ALSA. This is not for the main SDL port, but for the Linux port, which does not use SDL (for those users who do not have SDL). It was supposed to be a simple effort to change the MIDI sound from OSS to using ALSA, but ALSA documentation is so bad that it is just experimentation. Currently, I have it playing most of the time. Randomly, something resets the MIDI tick timer to 0. This causes the MIDI playing to stop until the tick time catches up to the MIDI stream position again. This could be due to using the wrong method to set the tick timer to zero, and it is just sitting in the queue, waiting for a random time to execute. Like, I said, raw experimentation. Could really use a method to detect when the ALSA MIDI kernel queue is empty. Not the one that you build MIDI messages into, but the one that it drains into. I need to detect when it is done, so it safe to change queue settings, and start another MIDI song. Been through the documentation so many times already and nothing there seems to detect that. Although I can read the current MIDI tick time. Been using that for now.
  12. wesleyjohnson

    A Small Idea I don't think would kill to implement.

    An additional element is Spatial Mapping. The placement on the sound indicator on the sound bars would correspond to spacial indication of the sound direction. Sounds to the front can be display at the top of the sound bars, and sounds behind the player can be display at the bottom. Left and right sound spatial location can use left/right relative intensities and/or left/right relative placement in the sound bar. If vertical indication of spacial location is used, then some horizontal indication of spatial location will be expected, and it would be confusing to not have it. The code can cheat and just use the source location, so there is no need to reconstruct this. The source of the sound is known, and additional information as to front-back can be passed as a parameter (which is used for quad sound too).
  13. wesleyjohnson

    A Small Idea I don't think would kill to implement.

    Subtitles are barely tolerable. I use them often to watch foreign programs. It is hard to pay any attention to action when you have to read subtitles all the time. You are going to get killed while reading "monster growls" instead of turning to defend yourself. Most every idea is going to run into the problem that sounds can be changed, and none of them have a textual description. There are massive number of existing wads that do not have any subtitle support. Knowing the sound name is of little use, as they were limited length and generally over-abbreviated. What would be better is "Visual Sound". Due to wide screens being wider than the normal Doom screen format, there are bars available at the left and right that can be used to display Stereo Visual Sound, and not have to overlay it on the screen. Most applications that have Visual Sound allow a selection of the display transform. The Visual Sound transform needs to have fast recognition, and a degree of inherent recognition is preferrable. 1. Frequency Graph. Run each channel through a FastFFT and display the frequency intensity in the Visual Sound bars. This can handle any sound without having to The user would have to learn to interpret the display, and associate each visual display with what produced the sound. Only the FFT and visual display is needed. No support information is needed from wads. Has no inherent recognition. 2. Icon Each sound play would have an icon that is displayed in the Visual Display area for the time the sound is playing. The sound volume can be used to control the icon size, or its brightness (or both). More important items like weapons would be placed at the top, monsters in the middle, and other sounds at the bottom. For monsters, the sprite frames are already available and can be displayed quickly. For other sounds, would have to add a visual sound icon for the sound. For most sound, we know what produced it, even if dehacked has changed the sound. Some appropriate icon could be created for each, even for Heretic environment sounds. This does require some support icons to be created, and some dehacked wads might want to modifiy the icons used to something more appropriate. This has high inherent recognition. 3. Abstract Patterns There would be a line draw based pattern generator that displays visual sounds. It would have several parameters, such as category, shape, danger-level, density, color, intensity. From these parameters it would generate a pattern. A particular sound would always generate a similar pattern, with sound volume mapped to intensity. Each sound would generate a pattern, using almost any sound data, such as a hash of the name. Monsters could have their own category and specific shapes. As it is abstract patterns, they must be learned and associated with the monster or action. This is much simpler to implement as it only requires the generator, and does not need any new information for dehacked wads. Due to the categories and shapes, it has moderate inherent recognition. Certain patterns are always monsters, and a relative danger ranking can be indicated in an inherent recognizable way even when the monster has not been encountered before.
  14. wesleyjohnson

    DoomLegacy 1.48.8 Release

    Finally making some progress on the X11 port bugs. Got the video problem mostly controlled. Got some new sound code, that finally actually produces some sound with ALSA (instead of just error messages). Have to tie up a number of loose ends, and incorporate a large amount of new code. There will be testing. Perhaps in a month there will be an X11 port release of DoomLegacy 1.48.8, with new features (the new features are X11 only).
  15. wesleyjohnson

    Try to Compile Doom Legacy for DOS

    I have not worked on legacy2. It is C++, uses oxygen, and gcc indentation style. The oxygen is annoying, the gcc indentation style does not agree with me, and C++ applied to a C program is like art-work with the clash of styles. The total reorganization makes it difficult to check code with PrBoom. I cannot find anything in that code. Legacy1 has accumulated over 1000 patches, many fixes and new capabilities, that have not been applied to legacy2. Legacy2 has Hexen, which I may copy over into Legacy1. Legacy2 needs a volunteer who is compatible with it. I am getting backlogged on so many projects now that I cannot see how that ever will be me.
×