This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Builderboy
Pages: 1 ... 18 19 [20] 21 22 ... 375
286
« on: March 29, 2012, 11:33:03 pm »
The best way to defend against imps is to continuously decrement the B field of the memory location 2 instructions above your program. If an imp hits that, it will fail to copy its statement to the next instruction and then die.
287
« on: March 29, 2012, 04:22:48 pm »
Yeah thats what mrmprog suggested
288
« on: March 29, 2012, 02:05:13 pm »
Ah I see, yeah that would be possible, I'll implement that ^^
289
« on: March 29, 2012, 12:00:40 am »
Ah I see, and that unfortunately is very difficult to change, as it affects a lot of different memory locations. I made it as large as I could before starting to eat into even more memory gained from appvars. Remember that each process takes 2 full bytes, so with a max of 64 processes, that is already 256 bytes of data.
290
« on: March 28, 2012, 10:00:31 pm »
Customizable process limits? What do you mean by that? Also since positions are relative, the first program starting at the 'begining' of the core is irrelevant
291
« on: March 28, 2012, 02:10:47 pm »
If over 9000 instructions are executed, the game is taken to be a draw. I might have to lower that limit 
292
« on: March 28, 2012, 03:21:15 am »
My first post was where I, until recently, hid the uploaded file for the PortalX closed demo
*Builderboy hides*
293
« on: March 27, 2012, 11:09:30 pm »
There is no assertion in my version of core wars, since the core size will remain constant across all versions. You can, however, use negative numbers, which will automatically be converted into the correct positive offset. So -1 will be converted to 1023 for example.
Also, mrmprog, the best way would be to make the increment of X a number that is divisible by the core size, like 8 or 16. That way as long as you start X in the right location, X will miss you each time it goes around. If you want the increment to be a value that isn't divisible by the core size, you would have to get a little tricky. Also, why are you splitting into so many different sub programs?
294
« on: March 26, 2012, 08:47:55 pm »
Nope, no tournament has been started yet, although a thread has been started where people have been sharing their creations for fun. And Homer, the issue I see with that rule-set is that games would be too short. Within 22 frames a program could have completely filled the entire core (6 to reach 64 processes, 16 to fill the core) and there becomes no opportunity cost to creating processes.
295
« on: March 26, 2012, 08:27:39 pm »
We should start a mini contest using Core Warriors! Who would be interested?
296
« on: March 23, 2012, 03:09:24 am »
When the RedCode Warrior you spent two hours tweaking in order for it to work can't even beat an Imp...
Imp is actually quite hard to beat with a general program, the only sure fire way of killing it is to make a program called impgate which is just JMP 0 )-1. But I wouldn't worry too much, cause Imp can't kill you either 
297
« on: March 23, 2012, 12:19:47 am »
Here is my recently coded Warrior. It first copies itself to a new location and starts a new process there, and then proceeds to start clearing the memory in front of it. It is hopefully both resilient because it has many processes, and hopefuly lethal since it is attacking a large percentage of the core.
:*ORG CPY
Lbl CPY
MOV )X }X
JMN CPY X
NOP (69 {69
SPL 61
ADD e2 X
Lbl CLR
MOV X (X
JMP CLR
Lbl X
DAT e73 e9
And here is a different version of the original bomber that instead of bombing with DAT instructions, bombs with SPL 0 instructions, causing your opponent to create unlimited numbers of subroutines, thus preventing them from functioning normally. After you finish bombing, your opponent should be subdued, so the program enters the 'clear' mode, where it goes through and clears every instruction until its opponent is dead
:*ORG TOP
Lbl TOP
MOV S /S
ADD e4 S
JMN TOP S
Lbl CLR
MOV D (D
JMP CLR
Lbl S
SPL 0 e8
Lbl D
DAT e0 e2
And here is the source, as well as a screenshot of them doing battle! Scan won that round, and as you can see, as soon as the Split Bombs hit the other program, all movement completely stopped and it's processes completely maxed out!
298
« on: March 22, 2012, 03:49:11 pm »
There should be a map of all getkey codes included with your axe download. Alternatively you could simply make a program that outputs the value of getkey, and press the keys you want to test! 
299
« on: March 22, 2012, 03:28:13 pm »
Sounds interesting, you should make a thread about it if it gets off the ground
300
« on: March 22, 2012, 01:52:05 pm »
You can make a new thread, and people can learn from everybody's examples ^^ And Storing to memory locations is done in general by the MOV command, which moves an instruction from one location into another. Different addressing modes and instruction modifiers can restrict and alter this behavior as well.
Pages: 1 ... 18 19 [20] 21 22 ... 375
|
Show Posts