Blzut3

This is called function inlining. However, to handle recursion, circular calls, and whatever else you still need a call stack. It could be solved by allocating a stack in an array, but you'll need a more advanced compiler than ACC to do this. Though if it were really a big issue then it would be something to solve at the VM level.

I guess to better explain how the VM works: Here's script 12 from Hexen's map01:script 12 (void) { int var0; int var1; mapvar3 = 1; while(var1 < 20) { while(var0 < 4) { Pillar_BuildAndCrush(40+var0, random(const:8, 32), 0, 20); tagwait(40+var0); Pillar_Open(40+var0, random(const:8, 32), 0, 0); var0++; } var0 = 0; var1++; } }The VM sees the following only in binary form (there are no rows):Script12: pushnumber 1 assignmapvar 3 BeginOuterLoop: pushscriptvar 1 pushnumber 20 lt ifnotgoto EndOuterLoop BeginInnerLoop: pushscriptvar 0 pushnumber 4 lt ifnotgoto EndInnerLoop pushnumber 40 pushscriptvar 0 add randomdirect 8, 32 pushnumber 0 pushnumber 20 lspec4 94 pushnumber 40 pushscriptvar 0 add tagwait // Script will block here until the tag stops moving pushnumber 40 pushscriptvar 0 add randomdirect 8, 32 pushnumber 0 pushnumber 0 lspec4 30 incscriptvar 0 goto BeginInnerLoop EndInnerLoop: pushnumber 0 assignscriptvar 0 incscriptvar 1 goto BeginOuterLoop EndOuterLoop: terminateWhen tagwait is hit, the "thread" is placed on the blocked queue until the tag stops moving. It is then moved to the ready queue and is executed on the next VM pass. The reason delay can't be used in a function is some VMs (ZDoom and I would assume Hexen), use a global stack which needs to be cleared between each script and consequently each tic. Because of this, when the execution resumes the call stack can not be unwound (so return wouldn't work). IIRC from my discussions with DavidPH, Eternity's VM does save the stack so it would be able to successfully execute a delay in a function.

You are correct in that the ACS VM run in a single thread so technically there is one big loop. However, the order that the scripts get executed is implementation specific. While technically trying to run scripts in multiple real threads would likely quickly run into a deadlock, you should imagine each script as its own thread running on a single core system. As for how this is implemented in C(++). You maintain a list of running scripts. ACS_Execute pushes a script onto the list. The ACS VM iterates through the list executing the script until it reaches a delay or terminates. If it delays it goes onto the blocked queue until the delay condition is met. At which point it is scheduled to run again. For a more in depth description look at operating system schedulers, in particular the simple FIFO scheduler which would likely be used by every ACS VM. (Since scripts always execute within a tic more complex scheduling algorithms aren't needed.) An important thing to remember is that ACC compiles to byte code (similar to Java or .NET) so the VM only sees a linear sequence of instructions which it needs to execute (with loops and conditionals telling the VM to jump to another point in the sequence).

I use a Samsung Galaxy Player 4.0 (aka Galaxy Wi-fi) with Google Voice. I don't get calls or texts often enough to make cell service worth the money and I'm connected to a Wi-fi access point most of the time any ways. On a side note, it's a shame the manufactures don't seem to interested in making a great Android PMP. I guess not servicing a Nexus is only a little more expensive than a PMP, so they have to cut costs somewhere.

http://debian.drdteam.org/

Perhaps it's time to port any useful information from there to the wiki and set up a redirect?

A few days ago Jim Lynch released the Hacx soundtrack on DVD-Audio. All 22 tracks have been "re-mastered by the composers using high-end synthesizers." The tracks are also available in full for streaming on the website.

A few days ago Jim Lynch released the Hacx soundtrack on DVD-Audio. All 22 tracks have been "re-mastered by the composers using high-end synthesizers." The tracks are also available in full for streaming on the website.

Actually forgot I wanted to post about it here. Sorry about that. He has been... surprisingly unhelpful. First I informed him about the AC3 64kbps audio, and even offered to remaster the disc for him. Here was his response: To make a quick comment on vinyl vs CD, I noted that CD audio is able to losslessly represent any sound the human ear can hear. To simply my request, I ask him if he would be willing to offer lossless FLAC renders for those who purchased the DVD (possibly with proof of purchase by forwarding the order confirmation). Specifically: "Really, the only reason someone would purchase the DVD is for perfect audio quality, so you should do something to rectify the situation." So his solution to the problem was to zip up the mp3s hosted on his site and send a link. Silly considering they're all available for download from the site. I reiterate that he should give lossless renders, and that I don't feel that this is asking too much from him. But seeing as I got no response I have to concur with your suggestion "Do Not Buy!" Perhaps his "high quality" synth is only able to produce mp3 files. :P

Not entirely true. There's a terminal command to disable the mouse acceleration by setting it to a negative value. Unfortunately that also means having the mouse at the slowest speed (not unbearable though), so I still recommend using Microsoft's driver.

I would argue that it's mostly fud. Some old hats don't trust compiler optimizations (back in the day compilers weren't that great at this) and feel that everyone should hand optimize their code. That or they strongly believe that expensive operations should be difficult to write in order to make you think twice. There's also a lack of education in that most of OOP is just syntactic sugar, so some people worry that C++ will automatically slow down their program. In reality, C++ is pretty much designed to not insert anything unless you explicitly call for it.

For those who are still unaware, I've been working on an advanced source port for Wolfenstein 3D based of Wolf4SDL and ZDoom. In short it allows full soft modding in a format very similar to ZDoom while still retaining the quirks of the Wolfenstein 3D engine. It is dual licensed under both the original non-commercial license and the GPL (although the official builds currently use the non-commercial license, the GPL edition only switches the OPL emulator). ECWolf 1.1 has been released today along with an updated tech demo. Builds are available for Windows, Mac OS X, and Ubuntu. My website links to some youtube videos of the engine as well. Edit: ECWolf 1.1.1.

You have to write a custom map translator. Look at the xlat/wolf3d.txt in ecwolf.pk3. Note that there's no particular location you need to put your translator file. In fact, I would recommend not naming it the same as ecwolf.pk3. You'll need to specify the translator to use in mapinfo. This post I made on the die hard wolfers forum may help a little even though I don't cover walls in particular. Also check out the techdemo's translator for another example.

Not at the moment. The sound code rewrite will happen in time for 2.0 though since the Mac wolf has a midi sound track.

HWE or WDC are recommended. I know WDC supports up to 180x180, not entirely sure what HWE's features are. ChaosEdit can be used, but you'll eventually want to use the other two in order to export the maps for proper packaging any ways.

Run it from the command prompt so you can view the output. Alternatively you can use a batch file to hold the window open until a key is pressed. IIRC the contents of the bat file would be:patchutil.exe pauseIf it's actually producing no text then you most likely have a modified version of Wolfenstein. If it works, it prints the version you have installed and then every subsequent version as it applies the patch. Edit: Example output:Patching: Wolfenstein 3D Registered GT #2 1.4 Patching: Wolfenstein 3D Registered v1.4

Sure. Feel free to PM the link if you don't want to share it publicly.

So awhile ago it came to my attention that the USDF spec is slightly out of line with the binary format. The description of the page block reads: However, both USDC and ZDoom have implemented it as starting from 1. This makes sense as the vanilla binary format hacked the sign for if the dialog should close on choices. Since all known implementations are in line, should I go ahead and change the spec to match this?

All right, I have committed the updated document there as well. Amusing side note, I just saw that the new spec is 6,666 bytes.

One important thing to note is that there is no compiled form of Z/USDF. USDC is a tool which takes a subset of the USDF standard and converts to vanilla compatible binary lumps. The compiler should, of course, warn should it have to discard information. The DIALOGUE lump in a UDMF map can be in either format. Be sure to look at the console for any parsing errors though. As far as "compiled" lumps go, vanilla Strife used SCRIPTxy to store them. Historically though, some editors put Hexen ACS script sources in SCRIPTxy so the detection logic of "binary or ASCII" wouldn't really work here. Because of this, Z/USDF scripts must be placed in a DIALOGxy lump instead when used with non-UDMF maps. It's difficult to say without the problematic WAD/PK3.

Somewhat true. That warning happens because the package is unsigned. If you sign it, then the key can be imported to remove that message. I haven't figured out how to get signing to work so I can't help you here (and not to mention importing a key for one package is probably more of a hassle than it's worth). The easiest thing to do would be to set up a ppa on launchpad. I believe that handles the signing and key distribution for you.

The DIALOGUE lump is to be used with UDMF format maps. It goes in the WAD file between the TEXTMAP and ENDMAP markers. If you are not using UDMF your map must be in MAPxy format and the script goes in the corresponding DIALOGxy lump.

I was probing around with the console ports of Hexen and noticed that as well (I believe this was in the N64 port). I wonder if the Mac port is based off of that? I would try the Mac version myself, but my Performa isn't hooked up to the network at the moment.

Since there are no objections the spec has been formally updated.

I don't know how obvious that is considering I don't think it's very often that you would get the chaingun before getting the machinegun unless you go out of your way to do so (or warp). Remember that games were developed much more quickly at the time. ID has been known to glance over "obvious" problems as well, for example the broken BJ breathing animation. :P I'm not exactly sure how to fix it so I might end up leaving it how it is. Perhaps I can expand the meaning of WeaponGiver or something. Any suggestions? Obviously it would be a matter of swapping out the actor in the map translator.