Browsing this Thread:
1 Anonymous Users
|
Anonymous
|
Re: DOOM Update
|
|||
|---|---|---|---|---|
|
joysticks! =o)
well, i have both paralell (directpad) (psx pad style) and gameport joysticks! |
||||
|
||||
|
Re: DOOM Update
|
||||
|---|---|---|---|---|
|
Home away from home
![]() |
Quote:
EDIT: Okay! Fixed the constantly changing music speed problem! I also added two new switches: -70Hz and -140Hz. Using -music alone plays the music at 35Hz. Using one of the new switches ALONG WITH -music plays the music at the specified rate. This can improve the quality of the music a little, but 140Hz doesn't work on hosted, and 70Hz on hosted can have drop-outs. I suggest sticking to 35Hz for hosted (which is why it's the default). I commited the changes to cvs server. BTW: It would be much easier/faster if you ask for cvs access and use cvs yourself, too. First of all you will no longer need to update whole sources when wanting to update to the latest ones. A "cvs -z3 update ." will do that, retreiving only files which differ from your local sources -> endless times faster. BTW2: For something funny try "execute start4" in Doom directory. But don't try that in native, only in hosted.
Posted on: 2004/9/25 17:00
|
|||
|
||||
|
Re: DOOM Update
|
||||
|---|---|---|---|---|
|
Home away from home
![]()
|
Just bumping the thread since my edit didn't bump it. :uh:
Posted on: 2004/9/25 10:02
|
|||
|
||||
|
Re: DOOM Update
|
||||
|---|---|---|---|---|
|
Home away from home
![]()
|
Okay, here's the DOOM files for people to try. The first link is a zip of the executable. The second is a zip of the two files which are changed. I renamed the executable just a little so that you can copy it in the Doom drawer and not overwrite the original Doom just in case.
aros_sound.c is completely changed, obviously. aros_system.c has only two additional lines. If you look at I_Quit() and I_Error() in the original file, you'll notice that I_Error() doesn't shutdown the music or sound. Timedemo uses I_Error() to print the fps and quit, so it leaves the sound and music running. This wasn't a big problem before as there WAS no sound or music. I had to add those lines to I_Error() from I_Quit() to keep timedemo from causing trouble. Remember that the MIDI instruments file is on aminet in the games section in the same section as the various Doom conversions which all used it. http://www.geocities.com/jlfenton65/Programs/Doom.zip http://www.geocities.com/jlfenton65/Programs/Doom-src-chgs.zip EDIT: Okay! Fixed the constantly changing music speed problem! I also added two new switches: -70Hz and -140Hz. Using -music alone plays the music at 35Hz. Using one of the new switches ALONG WITH -music plays the music at the specified rate. This can improve the quality of the music a little, but 140Hz doesn't work on hosted, and 70Hz on hosted can have drop-outs. I suggest sticking to 35Hz for hosted (which is why it's the default).
Posted on: 2004/9/19 6:45
|
|||
|
||||
|
Re: DOOM Update
|
||||
|---|---|---|---|---|
|
Home away from home
![]()
|
Quote:
I know. Getting high levels of switches out of hosted may depend on the kernel. I need to look into it more. There are some "real-time" modifications that can be made to 2.4 kernels to make multi-media work better which may also help AROS hosted on older kernels. Quote: task switch speed: here AROS native can do more than 10 million task switches per second. If the corresponding benchmark programs tell the truth. test/benchmark/exec/taskswitch.c and taskswitch2.c. Are not built automatically at the moment for some reason. You need to modify mmakefile.src to make them compile. Note also that taskswitch.c doesn't give a value per second, but number of task switches that have happened during time benchmark was running. Yes, native mode should do well, but as my last post indicated, the filesystem isn't up to the task of playing anything (games, videos, etc.). Quote: Or do you mean preemptive task switching? it's rate depends on ExecBase->Quantum and INTB_VERTB. Can't be very high by force. Not even on real Amigas. Higher priority tasks switch in regardless of what the quanta is for lower priority tasks. My sound task is a higher priority and waiting on the sound IO to complete. The completion (should) be at an interrupt level and brings the task out of wait-state to ready. Interrupt handlers finish by resheduling tasks. If a waiting higher priority task becomes ready, it switches in no matter how much time a lower priority task has left. I was able to do something similar on the Amiga using audio ints from Paula at several thousand per second. It made the system (030) about twice as slow, but it worked.
Posted on: 2004/9/18 22:06
|
|||
|
||||
|
Re: DOOM Update
|
||||
|---|---|---|---|---|
|
Home away from home
![]() |
Quote:
I did run into one thing while working on sound - Linux hosted AROS doesn't schedule tasks often enough. I use a seperated thread to fill and play double-buffered audio. It used to run at the beat rate of the music - 140 Hz. The problem was that AROS wouldn't switch the tasks quickly enough to keep the audio glitch-free. It would constantly break up. I switched it to half the beat rate, 70Hz, and now it's pretty clean. Problem: AROS timers at the moment have only precision of 50 Hz (INTB_VBLANK emulation, timer.device/UNIT_VBLANK). Also Linux itself has only low timer precision. 100 Hz. Only with 2.6 kernels they seem to have increased it to 1000 Hz, but many people (like me) still run 2.4 kernels. task switch speed: here AROS native can do more than 10 million task switches per second. If the corresponding benchmark programs tell the truth. test/benchmark/exec/taskswitch.c and taskswitch2.c. Are not built automatically at the moment for some reason. You need to modify mmakefile.src to make them compile. Note also that taskswitch.c doesn't give a value per second, but number of task switches that have happened during time benchmark was running. Or do you mean preemptive task switching? it's rate depends on ExecBase->Quantum and INTB_VERTB. Can't be very high by force. Not even on real Amigas.
Posted on: 2004/9/18 20:28
|
|||
|
||||
|
Re: DOOM Update
|
||||
|---|---|---|---|---|
|
Home away from home
![]()
|
Quote:
Actually, DOOM doesn't work at all in native AROS. It hangs at "R_Init: Init DOOM refresh daemon". This is under the 9/17/2004 AROS native code with the "stock" Doom, so it's not my sound code causing the problem. I'll look into it. I'd like to see how native compares to hosted. I did install Linux on that system, a dual-Celeron 550MHz system, and Doom gives 37FPS at 640x480 without any sound, and 34FPS with both sound effects and music. Not bad for running on an old 550MHz Celeron. The system is an ABit BP6, perhaps the most popular multi-processor mobo ever made. It is an Intel 440BX mother board with an APIC interrupt chip handling two Celeron CPUs (or two Pentium IIIs with adapter sockets). When Intel heard ABit was selling dual processor boards by the bucketful cheap, they immediately removed dual-CPU support from the Celeron and P3 lines to put an end to that... can't go letting people have dual-CPUs cheap now, can we? :uh: For most OSes, it simply resembles a standard 440BX mobo with a single Celeron. OSes which can take advantage of multiple CPUs get two Celerons. Fedora Core 2 SMP seems to run rather well on it. It's really responsive - more than you'd expect from an old Celeron system. You can usually buy BP6 mobos on eBay for about $100. That's how I got mine. $105 for the mobo, two 550MHz Celerons, and 256M of PC100 memory. Not bad if I do say so. It makes a nice test machine. I threw a SB PCI512 card (a SB Live card before they started calling them SB Live) in it and it works well with the emu10k native driver. I use a Radeon 7200 for the video. Nothing to brag about, but it does well enough. I can play TuxRacer full speed on the 7200 on this system, so it's not all bad. I don't think I'll be playing DOOM3 on it though. EDIT (at 5:30 in the freakin' mornin'!!): Okay, DOOM does work in native... it's just that the freakin' filesystem is SO DAMN SLOW that it's unuseable. I let DOOM sit for hours and it eventually ran... like molasses. Damn... now I gotta write decent filesystem... Okay, so DOOM sounds seems okay. I'll put up something TOMORROW for folks to check out... in hosted, then I'll start working on "fixing" the filesystem for native mode. I had the idea to wait when I remember that copying the files during the install onto the harddrive took HOURS to do. Then I remembered that the R_Init() loads all the WAD file objects (textures etc) for the level. That does LOADS of tiny seeks and loads all over a 12-20M file. SO I figured Doom wasn't really stuck, just as slow as the install. So I went to bed and set my alarm so I could check it a few hours later... :zzz:
Posted on: 2004/9/18 7:27
|
|||
|
||||
|
Re: DOOM Update
|
||||
|---|---|---|---|---|
|
Home away from home
![]()
|
Well, I had to drop the beat rate to 35Hz, but it sounds remarkably good for music meant to be played at 140 beats per second. The code doesn't do anything fancy like interpolate the samples, but it still sounds pretty good for 11025 Hz 8-bit samples (remember, Doom is a decade old).
I'm installing the native AROS on a system to check it out in native mode. After that, I'll post it here for others to try. Get the midi instruments archive off AmiNet for the music. You'll find it in the same section as ADoom and ADoomPPC. I can't believe I did those instruments a decade ago... where does the time go? The midi instruments file goes in the same folder as the DOOM executable as the code just tries to open "PROGDIR:MIDI_Instruments", so don't change the name either. There is a low-quality version of the midi instruments, but given the size of modern systems, you should just use the higher-quality one instead. It only takes 4M. I'll probably do sound for Quake after this, then look into updating MAME to the latest version. Let's get some of these extras whipped into shape!
Posted on: 2004/9/16 17:47
|
|||
|
||||
|
Anonymous
|
Re: DOOM Update
|
|||
|---|---|---|---|---|
|
Great! =o)
under native does it worked well? (you mention under host) maybe quake will be the same! (im not sure but i think doom and quake has the same file structure)...unfortunelly we dont have mame atm...mame with sound (and uae) would be very good! regards, |
||||
|
||||
You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create PDF files.
You cannot get print page.





