[MusicallyInspired]

Can't make 64-bit for Win7?

[icecoldduke]

MusicallyInspired, on 13 April 2016 - 02:10 PM, said:

Can't make 64-bit for Win7?

As I said I will make a Win32 project so I can support 64-bit Win7. I will probably do that after I get the albedo pass, sound and input all working properly. I'm simply saying the code I am in the depot at this time only supports Windows 8, 10, and XB1. This is only because I only have UWP projects at the moment. As soon as I make some small code changes and the Win32 projects, everything will just work on 7.

[Hendricks266]

icecoldduke, on 13 April 2016 - 05:26 AM, said:

Speaking of audio, I might be ditching jfaudio. In UWP Microsoft doesn't support the mmsystem library, which means I loose the midi synthesizer. I might be going with fmod instead, which also means I don't have to write a XAudio2 implementation. To get around the GPL issue with FMod, I would write the replacement audio stack in the build module, since build isn't gpl'ed, this would make fmod license ok I believe.

You're showing a remarkable lack of understanding. You don't need to ditch AudioLib. In fact, it is essential to the game sounding right. All you need to do is change the driver that connects the library to the OS subsystem.

Or, you know, not, because we use SDL extensively and SDL supports UWP. Why are you not using SDL?

You're gutting ten years of systems engineering because you don't understand our codebase. Inb4 your renderer crashes and burns in any of BUILD's odd use cases like overlapping sectors.

[icecoldduke]

Hendricks266, on 13 April 2016 - 03:51 PM, said:

You're showing a remarkable lack of understanding. You don't need to ditch AudioLib. In fact, it is essential to the game sounding right. All you need to do is change the driver that connects the library to the OS subsystem.

Or, you know, not, because we use SDL extensively and SDL supports UWP. Why are you not using SDL?

You're gutting ten years of systems engineering because you don't understand our codebase. Inb4 your renderer crashes and burns in any of BUILD's odd use cases like overlapping sectors.

I wasn't aware that SDL supported UWP. That solves the issue then. I am all for the fastest way to do something, you don't need to get defensive. I was in no way knocking the AudioLib. I just had no interest in writing a XAudio2 code and I definitely had no interest in writing my own midi synthesizer. Therefore it was a solid plan to ditch the AudioLib, and go with FMOD. Not because of bad coding, but because it would have been the fastest way to ship. I believe I could have got the sound sounding just like the original. I'm going to shelve my fmod work, and try the UWP SDL_Mixer. If that works, I'll do another video with sound working tonight.

I have a feeling though I going to have to do more work to get MIDI stuff to work(since at least on Windows its going through mmsystem, but that could just be the way I have the projects setup). As long as SDL_Mixer can handle MIDI, I'm good.

To top that off Evan, give me a map that has sector over sector that you think will crash PolymerNG, I'll take your map rendering challenge .

[Mblackwell]

I don't think he meant literally crash.

[Tea Monster]

Hendricks talks that way to everyone.

[icecoldduke]

Mblackwell, on 13 April 2016 - 04:36 PM, said:

I don't think he meant literally crash.

Tea Monster, on 13 April 2016 - 04:37 PM, said:

Hendricks talks that way to everyone.

I just wanted to clarify that I wasn't knocking any part of the eduke32 codebase. My goal here is to ship. Ditching the audiolib was a calculated decision so I could ship. I'm going to try what Hendricks suggested with the UWP SDL2. Hopefully it just works I'll post back with the results. .

[icecoldduke]

So looks like sound effects work, midi doesn't yet.

[Mark]

See how great things go when everyone in the sandbox plays nice?

[HiPolyBash]

There could even be progress if everyone didn't constantly shit all over each others ideas.

[Tea Monster]

Hendricks266, on 13 April 2016 - 03:51 PM, said:

You're gutting ten years of systems engineering because you don't understand our codebase. Inb4 your renderer crashes and burns in any of BUILD's odd use cases like overlapping sectors.

It might be an idea to sort out the many problems with our current renderer, or to address the multiplayer issues, before taking this attitude with others. Glass houses, etc.

[icecoldduke]

Audio and Music works now. MIDI is not going to be supported for the time being, I'm using the HQ OGG files from the HRP site.

[Mblackwell]

icecoldduke, on 13 April 2016 - 05:44 PM, said:

So looks like sound effects work, midi doesn't yet.

You want Timidity.

[icecoldduke]

Mblackwell, on 13 April 2016 - 07:34 PM, said:

You want Timidity.

This might be a disappointment to some people, but midi won't make it for the first release. HQ music works and for now, and imo midi isn't high enough of a priority to hold back the first release.

Items holding back the first release:
1) Input!
2) Hidden Wall rendering bugs.
3) Dynamic Sectors
4) Sprite rendering

[Mblackwell]

So, first release can't play the vanilla game?

[icecoldduke]

Mblackwell, on 13 April 2016 - 08:16 PM, said:

So, first release can't play the vanilla game?

It will play the vanilla game with HQ music rather then midi.

[Mblackwell]

But that's not vanilla game and assets then. You should be able to just load Duke3d.grp without modifications and play.

[Spiker]

You need to have a lot of patience and understanding to actually make something on these forums.

[icecoldduke]

Mblackwell, on 13 April 2016 - 08:33 PM, said:

But that's not vanilla game and assets then. You should be able to just load Duke3d.grp without modifications and play.

You can just load the Duke3d.grp file, just you won't get any music. Once you download the HQ music assets you will get music. MIDI assets are not a high priority issue. I want to get a build in the public hands so people can start catching bugs. I have done a lot of modifications to the engine, not to mention PolymerNG is a completely redone renderer. The only tasks I care about going forward to first release is getting the build playable with everything operating properly minus midi's. Remember ogg music works, just midi music does not.

I want people to start loading mods on the XB1. I think it will be pretty awesome to see the Blood EDuke32 port running on the XB1.

I understand your annoyed. The fact is I am only one person, and my time has to be managed in such a way that we get something awesome in people's hands to start finding bugs. I doubt there are going to be people who would have played the build, who now aren't because they have to listen to HQ music rather then midi music. Therefore my decision is final.

[Mblackwell]

Timidity is part of SDL_mixer. It takes about as much effort as the rest of the sound system and is already part of EDuke32 as it is.

[Spiker]

When he said he will add midi support why does he have to make it at the exact fucking second?

[Mblackwell]

Because it's already been done fucking twelve years ago.

[icecoldduke]

Mblackwell, on 13 April 2016 - 08:53 PM, said:

Timidity is part of SDL_mixer. It takes about as much effort as the rest of the sound system and is already part of EDuke32 as it is.

EDuke32 vanilla doesn't use Timidity, at least not on Windows. If you look at mpu401.cpp, that entire module has to be redone since mmsystem isn't supported on UWP. I missed something very obvious today when I tried to redue the audio stack with FMOD rather then going with SDL. It's possible I missed something else with the midi code, and maybe there is another drag and drop fix to get midi to work. It's very possible Timidity doesn't work on the Xbox. The fact is there are two many unknowns for me to warrant spending time on the midi code right now.

When I release the source code to PolymerNG I will glady accept any changes that add midi support back into the code, that works on the console and PC. In the highly likely event that doesn't happen, I will add it in when I get time.

[Danukem]

Mblackwell, on 13 April 2016 - 08:56 PM, said:

Because it's already been done fucking twelve years ago.

But he knows there are going to be renderer bugs and wants to make fixing them the immediate priority. The first release is going to have a long way to go in many respects so why does it matter whether it happens to have midi support? He has a development process that obviously is working well for him; it would be nice if everyone could be supportive without all the bitching.

[Mblackwell]

Oh shit, yeah that's right.

A renderer is the goal.


Not a sound system.









Oh, wait.

[icecoldduke]

Mblackwell, on 13 April 2016 - 09:25 PM, said:

Oh shit, yeah that's right.

A renderer is the goal.

Not a sound system.

Oh, wait.

Take a look at the code for yourself. The only code path I can find for midi's is MUSIC_PlaySong(music.cpp) calls into MIDI_PlaySong, from there the midi logic calls the core midi synthesizer, which seems to be all the MPU* calls that are located in mpu401.cpp. That entire module I can't use on UWP cause it makes calls into a unsupported set of functions. Mmsystem which is the foundation of the midi code that is in current EDuke32 doesn't work in UWP. The mpu401.cpp rewrite is simply outside the scope of the first release. I'm sorry.

If TerminX or Hendricks can point me to some code that already calls into SDL_Mixer for handling midi's that I can use to replace mpu401.cpp I would do it in a heartbeat. I can't find any code in the current SVN that does just that. Until I have time, the mpu401.cpp re-write will have to wait. Which means midi's won't work.

[Hendricks266]

sdlmusic.c

You'll have to look at the Makefile to see how it is built on non-Windows platforms.

[icecoldduke]

Hendricks266, on 13 April 2016 - 09:47 PM, said:

sdlmusic.c

You'll have to look at the Makefile to see how it is built on non-Windows platforms.

Yeah this work is going to have to wait till after the first release. Sorry guys this is the last word on it.

[MusicallyInspired]

I may be biased, but in my opinion you can't get any more vanilla than using the music pack recorded the way it was meant to be heard. Unless maybe you used the OPL3 music pack someone (High Treason?) released ages ago (as most people didn't have a Sound Canvas). But I don't think that one has embedded metadata loop tags. Technically, there's nothing "vanilla" about how the MIDIs sound on computers in 2016.

Will FLACs also work in this first build for the audiophiles we have here? For that matter, the metadata loop tags? I assume it would all work as EDuke32 currently functions anyway just without MIDI...?

[icecoldduke]

MusicallyInspired, on 14 April 2016 - 08:57 AM, said:

I may be biased, but in my opinion you can't get any more vanilla than using the music pack recorded the way it was meant to be heard. Unless maybe you used the OPL3 music pack someone (High Treason?) released ages ago (as most people didn't have a Sound Canvas). But I don't think that one has embedded metadata loop tags. Technically, there's nothing "vanilla" about how the MIDIs sound on computers in 2016.

Will FLACs also work in this first build for the audiophiles we have here? For that matter, the metadata loop tags? I assume it would all work as EDuke32 currently functions anyway just without MIDI...?

I can't remember which audio pack I used, I downloaded one from http://hrp.duke4.net/download.php, then copied all the ogg files to the same folder that the duke3d.grp is in. FLAC I'm not sure about.