Well, here goes. A new TAS dedicated to Warcraft I: Orcs and Humans.
I'm right at the start of the first orc level, and it begins.
Current strategy is to finish the first level without optimizing too much, produce a WIP and then refine it until it is good enough. Repeat for every level.
The problem is that I suck at RTSes. (Or any other kind of game, really.)
So, level one.
Objective: Build farms and barracks.
The first thing is obvious: Switch the game to "fastest". Easy enough.
Then what? I guess I will have to figure that out.
I intend to experiment with looking for glitches. Two things that would help the most are a way to harvest lumber faster and high-speed combat glitches. I will do the research and see.
I assume you are going to do separate Orc/Human movies, right? That would probably be best.
I'll be curious to see how this looks. Good luck!
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Two movies. One orc. one human.
High speed combat is a failure.
Once a unit starts moving onto a square it is committed to keep moving that way. There is no trivial way to dodge a blow that is being delivered. The best that I can do is to set my units up to deliver the first blow.
There may be opportunities to dodge catapults or to use catapults with perfect accuracy.
It seems like using the mouse is actually slower in many cases. Keyboard is better whenever possible, usually one frame faster. With the mouse I seem to have to click, advance, click and advance to get where I want to be. With the keyboard it is just a matter of press, unpress and advance.
Tomorrow logging/mining/building research. Then to plan the stage more carefully.
EDIT: When you build something your money starts to decrease slowly, kinda like life in Earthbound. Might be worth a try to play with building stuff in quick succession.
And time for something that is likely to become a recurring feature...
------- Complaining time!
The emulator is a great headache. Keyboard keys stick. Yuck! I'd love to be able to frame advance using F when the active window is the virtual keyboard. As it is, I have to switch back and forth. I'm not sure if the mouse sticks or not, even after playing for two days. Awful. No visible mouse press indicator either. No autofire. Trying to hold F for steady rolling made the emulator choke. Even when running without frame advance it takes forever to get anywhere. This slowdown effect is nice, but I'd love to turn it off or regulate it on the fly. (And it's a fairly new computer too!) If not for c-square I'd not even have good mouse control. I'm also not getting sound when emulating, but that may be just my own issue. It works in the dumps.
Emulator doesn't have sound regardless, I don't think it's built in anyway.
You press 'F' on your own keyboard, but if you press Shift (on your keyboard) while pressing the virtual keyboard keys (using your mouse), then they don't stick, but the button press is sent. This way you can send in the button presses on the virtual keyboard and frame advance on your own but afaik you need to have the emulator window itself active for the frame advance.
I don't think the mouse support is inbuilt (what c-square has is probably the most advanced). I don't know about a running normally either.
Yeah, the shift tip does work. Yay! Thanks.
Building things in quick succession is a failure. Even when the display still shows good numbers, building is no longer allowed when I don't have the resources.
This may mean having to deal with the economy. Harvesting 100 of lumber takes 15+ seconds on the fastest setting. I'd love to see if there is a good way to speed it up but...
------- Whine time!
No easy memory watch. No, a manual hex dump does not count.
-------
A farm costs 300 lumber. We need, I believe, 6 farms. One is provided for us. We have the lumber for one and a bit. That leaves (5x300)-400=1100 lumber for farms alone. That is 11 loads. Plus five for barracks. 16 loads. At least 240 peon-seconds, keeping in mind that I stopped counting after 15 seconds of seeing the peon hack away at the trees. Likely much much more.
Goldwise we need a fair bunch of gold as well. We start with 1000, enough for two farms. There is a mine nearby with 3000 gold to be mined. That buys the farms and the barracks leaving 900 gold to spare before we have to use distant mines. That translates to two peons. Of course all that mining translates to more peon-seconds.
So level 1 is going to be long and boring. :(
I don't remember exactly how it works in Warcraft 1, is there a limit to the number of peons that can be in a mine at once? Maybe the only limit is that workers are still "solid" in collision detection so that there can be a traffic jam between the mine and the base. (In later games, workers can pass through other units while mining.)
About collision detection, I'm pretty sure it works like this: when a unit starts moving from square A to B, the B square is directly the "real" location of the unit, and the unit can be hit by a unit next to this quare. For this reason, it is best to stop your units when charging, so that the enemy units walk the last step to you.
You are correct about squares A and B.
I aim to play more with high-speed combat.
Today the aim is to play like this:
O - Orc
H - Human
H..O
.H.O - Human starts moving onto the tile next to the Orc. I attack. I start moving back.
..H.O - I attack again, repeat.
This may give me an extra hit or two, at the cost of nanomanaging (yay, I made a word!) my units.
Given this
...O
H..O
...O
I can get hits... maybe, I have to try.
Did not research gold harvesting yet, lumber is depressing enough.
For lumber I guess the only important thing is to chop the trees closest to the drop-off point. Do number of chops at trees stack, can two workers chop the same tree twice as fast? Or does that mean that chops are lost? I can't remember.
I guess there is some optimization to be done about roads, and where units exit buildings. I think the standard is top left, what happens if you block this square?
I guess I should test stuff myself instead of just asking questions...
I would love to find out about chops stacking.
I'd do it with memory watch.
------ Whine time!
There is no memory watch.
And with the performance being horrible (~90 seconds of game in 15 minutes real time!) experimentation is not exactly fun to do. I have read two chapters of Master and Margarita while waiting for the emulator. If I run out of the book, I quit. Guess it is time to mess around with the defaults. Oh, wait. Cannot do that. Have to start over to do that. Great. Guess I'm stuck.
--------
But seriously, do give me ideas of things to try if you have any, I'm new to all this...
EDIT: It takes 22.5 seconds to chop a tree. 49 chops.
EDIT: Interrupting a peon causes the job to reset. I have a chap sawing at a tree for good 70 seconds now with a few frame interruptions here and there. Still nothing. Redirecting the job to another tree also does reset the job. I wager that two peons in fact don't chop down the same tree any faster than one peon, but this is not tested.
EDIT: I'm on chapter 4 of the book. Trying to tweak the performance of the emulator. Due to the construction of the sack of shit that the emulator is it won't be easy. It is a microcode interpreter. An idiotic approach if performance is anywhere near your goals.
More than one peon can be in a mine at the same time. It takes a bit over a second to mine a bag of gold. Finally some good news there! Gold is quick to get. Lumber sucks.
Now to ponder a trade-off. Get more peons at the cost of having long transit times to get gold or to try to make do with just three that let us not use the distant mines. We start with enough food for only one peon, but that can be fixed with a horrible fate meeting one of the starting grunts... Heh. Heh. Heh.
I'm going to get dosbox for experiments, this emulator will have me burned out before I can say "FED UP!". Is there a different dos emulator that has any tas tools, even if not accepted for submission?
:(
Profiling shows two parts of code that eat a lot of the time: Executing microcode and running the clock.
The clock looks mostly optimal, I chopped out a couple of bits that just give an informational message, but that (not surprisingly) did not result in any major speedups, if any.
Nothing that I can take out of the microcode part, not without deep thinking anyway.
I will try to switch some of my Java settings around as well. As is, making this run is impossible. Too slow. I can cope with anything else, but the lack of freedom to experiment is killing me.
Profiling shows two parts of code that eat a lot of the time: Executing microcode and running the clock.
The clock looks mostly optimal, I chopped out a couple of bits that just give an informational message, but that (not surprisingly) did not result in any major speedups, if any.
Actually, one could optimize it (don't know how much) by not polling for timers every instruction, but only for known timer events:
The timer would be run on:
* Ucode block abort/exit
* Before waiting (HALT)
* After there would be known timer event.
The cached next event would have to be updated after:
* Ucode block entry
* After any operation that can execute timer events (including HALT and polling for timers).
The only thing that can unpredictably add timer events in the middle of ucode block are input events, and internally those are added by timer events, in order to guarantee that the sequence is repeatable (furthermore, there is never a long gap between two timer events, since there's always activity going on).
haslomaslo1 wrote:
Nothing that I can take out of the microcode part, not without deep thinking anyway.
If you want to deal with some real black magic code: The JIT CPU core from original JPC, that should be much faster, but unfortunately making it work is far from trivial (I tried to make it work today, got lots of cryptic runtime errors).
Here is rough listing of things that have been done to the CPU core:
- CodeBlockManager has dummy methods to save/load it:
* void dumpSRPartial(SRDumper output)
* CodeBlockManager(SRLoader input)
* This class implements interface SRDumpable.
- New ucode op: INSTRUCTION_START.
* This ucode is emitted as first ucode op of every instruction (by both x86 to ucode compilers (one for real and one for protected mode).
* It advances the clock (if HALT is not in progress, as otherwise halt being aborted would advance clock twice), checks for self-modification of current block (aborting the block if it finds one if certain CPU flag is set).
- FPU handling is split to FPU class itself.
- Modifications to HALT in protected mode to cut down message spam from some games (those call HALT a lot from CPL != 0, which would normally trigger a message).
There are two new processor exceptions, neither of which is to be passed to the quest: TRACESTOP and SELFMODIFY
TRACESTOP is raised by INSTRUCTION_START if cpu.eflagsMachineHalt is set. This causes block to abort, with cpu.eflagsLastAborted being set and CPU instruction counter backing one place.
SELFMODIFY is actually handled the same way as TRACESTOP by the CPU core. It is raised by INSTRUCTION_START if current ucode block has been modified.
So, I managed to get Warcraft running on Dosbox.
Testing:
- Tree chops don't stack. They are counted on the worker, not the tree. The workers will need some micromanaging, because they are stupid and often select the same tree to cut down, which leads to waste.
- If there are workers nearby, the enemy will focus on killing them first. Sometimes they even ignore being attacked by other units. Perhaps this can be abused by bringing a worker to the battle and running him around like bait?
- The pathing sucks and units need to be micromanaged to take good paths. They often run into trees and take detours to reach somewhere.
- Sometimes, hits seem to miss and no damage is dealt. Random?
- It would be nice to know how much extra damage the upgrades do. There are no numbers for the lifebars or the attacks.
I quit.
The emulator is too slow and clunky.
Maybe in a year or two, once things improve a bit.
The bare minimum of what I need:
- Running at 15 fps minimum.
- Mouse button status clearly displayed.
What I'd actually like on top of the above:
- Easy memory watch.
- Undoing savestates.
- Adjustable slowdown.
- Running at 30 fps, which is still not ideal but much better.
- Frame advance working with the virtual keyboard selected.
I quit.
The emulator is too slow and clunky.
Maybe in a year or two, once things improve a bit.
The bare minimum of what I need:
- Running at 15 fps minimum.
- Mouse button status clearly displayed.
What I'd actually like on top of the above:
- Easy memory watch.
- Undoing savestates.
- Adjustable slowdown.
- Running at 30 fps, which is still not ideal but much better.
- Frame advance working with the virtual keyboard selected.
There are a few things that you can do, such as set hotkeys for the virtual keyboard, so you don't need to click it individually. However, I have to agree that JPC-rr is too slow to do really intense games like this. Perhaps Ilari could attempt to implement his changes which would increase the speed.
You may want to check out my PSX Warcraft 2 TAS. While using a controller sucks, it is easier to TAS at the moment.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
