• 0

Cracking, the way is used to be


Question

Hello folks, im here to ask the help of a directX programer, me and the guys have been playing forsaken for years and we think its time to setup our own server but....... the patch for the game that supports server mode plays about 25% slower. I was hoping someone could have a look at the patch and set it back to the origanal speed.

more details will follow on request.

Thanks for any help :)

Link to comment
Share on other sites

16 answers to this question

Recommended Posts

  • 0

I don't know any games that put NOOP (no operation) codes in simply to slow the game down and annoy the player. Chances are that any additional code is required to fix a bug or something, and you'll be lucky to write replacement code that does the same thing in less time.

Link to comment
Share on other sites

  • 0
I don't know any games that put NOOP (no operation) codes in simply to slow the game down and annoy the player. Chances are that any additional code is required to fix a bug or something, and you'll be lucky to write replacement code that does the same thing in less time.

Project Director: "OK team, I was talking it over with the execs last night, we've decided that we think we can really **** some people off if we slow the game down about 25% in multiplayer with this next patch!"

Team: "SWEET!"

Yep, that's exactly how it works.

Link to comment
Share on other sites

  • 0

you still play forsaken ? i think that game came with my first PC that had Creative Labs Riva TNT , 16 MB but it was OEM.

I did play forsaken on Nintendo 64!! it was good game ,my friend was obsessed with it.

best weapon in forsaken is that powerful bomb or what it is. that wipes almost everything out in the room/area.

Link to comment
Share on other sites

  • 0

ok i hope you guys read this. the game was slown down to try and counter act the lag issue that all the players were complaining about. so... coz they couldnt be botherd to rewrite the network code they just made the game slower

Link to comment
Share on other sites

  • 0
I don't know any games that put NOOP (no operation) codes in simply to slow the game down and annoy the player.

how can a NO OPERATION slow anything?

i mean it does nothing?

like you put 10k nop's and you get a slowdown????,what does this have to do with the limit he has on speed of the game?

Link to comment
Share on other sites

  • 0

!NOOP

Name

!NOOP -- Performs no operation.

Synopsis

!NOOP

Description

The !NOOP action does not perform any task. It is short for "no operation". This is used when you do not want any actions to be executed. In Controls with a Input Interface that has Options, if an option does not have an action following it and that option is selected, then the next action that is found is executed. So if you do not want any actions to be executed if a certain option is selected, then you must put a !NOOP action directly after the option.

Example 1. !NOOP example

One major concept that differentiates this virtual assembly language from its real-world counterparts is in the additional uses of nop instructions (no-operation commands). These have no direct effect on the virtual CPU when executed, but often modify the effect of any instruction that precedes them. In a sense, you can think of them as purely regulatory genes. The default instruction set has three such nop instructions: nop-A, nop-B, and nop-C.

The remaining instructions can be seperated into three classes. The first class is those few instructions that are unaffected by nops. Most of these are the "biological" instructions involved directly in the replication process. The second class of instructions is those for which a nop changes the head or register affected by the previous command. For example, an inc command followed by the instruction nop-A would cause the contents of the AX register to be incremented, while an inc command followed by a nop-B would increment BX.

The notation we use in instruction definitions to describe that a default component (that is, a register or head) can be replaced due to a nop command is by surrounding name with ?'s. The component list is the default one to be used, but if a nop follows the command, the component it represents in this context will replace this default. If the component between the question marks is a register than a subsequent nop-A represents the AX register, nop-B is BX, and nop-C is CX. If the component listed is a head (including the instruction pointer) then a nop-A represents the Instruction Pointer, nop-B represents the Read-Head, and nop-C is the Write-Head. Currently the Flow-Head has no nop associated with it.

The third class of instructions are those that use a series of nop instructions as a template (label) for a command that needs to reference another position in the code, such as h-search. If nop-A follows a search command, it scans for the first complementary template (nop-B) and moves the Flow-Head there. Templates may be composed of more than a single nop instruction. A series of nops is typically abbreviated to the associated letter and separated by colons. This the sequence "nop-A nop-A nop-C" would be displayed as "A:A:C".

The label system used in Avida allows for an arbitrary number of nops. By default, we have three: nop-A's complement is nop-B, nop-B's is nop-C, and nop-C's is nop-A. Likewise, some instructions talk about the complement of a register or head -- the same pattern is used in those cases. So if an instruction tests if ?BX? is equal to its complement, it will test if BX == CX by default, but if it is followed by a nop-C it will test if CX == AX.

I've often considered to moving to four nop instructions by default; A, C, G, and T with the expected complements.

Instruction Set Reference

The full instruction set description is included here. An abbreviated description of the 26 default instructions is below.

(a-c) nop-A, nop-B,

and nop-C No-operation instructions; these modify other instructions.

(d) if-n-equ Execute next instruction only-if ?BX? does not equal its complement

(e) if-less Execute next instruction only if ?BX? is less than its complement

(f) pop Remove a number from the current stack and place it in ?BX?

(g) push Copy the value of ?BX? onto the top of the current stack

(h) swap-stk Toggle the active stack

(i) swap Swap the contents of ?BX? with its complement.

(j) shift-r Shift all the bits in ?BX? one to the right

(k) shift-l Shift all the bits in ?BX? one to the left

(l) inc Increment ?BX?

(m) dec Decrement ?BX?

(N) add Calculate the sum of BX and CX; put the result in ?BX?

(o) sub Calculate the BX minus CX; put the result in ?BX?

(p) nand Perform a bitwise NAND on BX and CX; put the result in ?BX?

(q) IO Output the value ?BX? and replace it with a new input

® h-alloc Allocate memory for an offspring

(s) h-divide Divide off an offspring located between the Read-Head and Write-Head.

(t) h-copy Copy an instruction from the Read-Head to the Write-Head and advance both.

(u) h-search Find a complement template and place the Flow-Head after it.

(v) mov-head Move the ?IP? to the same position as the Flow-Head

(w) jmp-head Move the ?IP? by a fixed amount found in CX

(x) get-head Write the position of the ?IP? into CX

(Y) if-label Execute the next instruction only if the given template complement was just copied

(z) set-flow Move the Flow-Head to the memory position specified by ?CX?

An example Ancestor

The following organism is stored in the file organism.heads.15, which you should find in the source/support/config/ directory. This is a simplified version of organism.default and organism.heads.100, of lengths 50 and 100 respectively (each has additional instructions placed before the copy loop)

# --- Setup ---

h-alloc # Allocate extra space at the end of the genome to copy the offspring into.

h-search # Locate an A:B template (at the end of the organism) and place the Flow-Head after it

nop-C #

nop-A #

mov-head # Place the Write-Head at the Flow-Head (which is at beginning of offspring-to-be).

nop-C # [ Extra nop-C commands can be placed here w/o harming the organism! ]

# --- Copy Loop ---

h-search # No template, so place the Flow-Head on the next line (to mark the beginning of the copy loop)

h-copy # Copy a single instruction from the read head to the write head (and advance both heads!)

if-label # Execute the line following this template only if we have just copied an A:B template.

nop-C #

nop-A #

h-divide # ...Divide off offspring! (note if-statement above!)

mov-head # Otherwise, move the IP back to the Flow-Head at the beginning of the copy loop.

nop-A # End label.

nop-B # End label.

This program begins by allocating extra space for its offspring. The exact amount of space does not need to be specified -- it will allocate as much as it is allowed to. The organism will then do a search for the end of its genome (where this new space was just placed) so that it will know where to start copying. First the Flow-Head is placed there, and then the Write-Head is moved to the same point.

It is after this initial setup and before the actual copying process commences that extra nop instructions can be included. The only caveat is that you need to make sure that you don't duplicate any templates that the program will be searching for, or else it will no longer function properly. The easiest thing to do is insert a long sequence of nop-C instructions.

Next we have the beginning of the "copy loop". This segement of code starts off with an h-search command with no template following it. In such as case, the Flow-Head is placed on the line immediately following the search. This head will be used to designate the place that the IP keeps returning to with each cycle of the loop.

The h-copy command will copy a single instruction from the Read-Head (still at the very start of the genome, where it begins) to the Write-Head (which we placed at the beginning of the offspring). With any copy command there is a user-specified chance of a copy mutation. If one occurs, the Write-Head will place a random instruction rather than the one that it gathered from the Read-Head. After the copy occurs (for better or worse), both the Read-Head and the Write-Head are advanced to the next instruction in the genome. It is for this reason that a common mutation we see happening will place a long string of h-copy instruction one after another.

The next command, if-label (followed by a nop-C and a nop-A) tests to see if the complement of C:A is the most thing copied. That is, if the two most recent instructions copied were a nop-A followed by a nop-B as is found at the end of the organism. If so, we are done! Execute the next instruction which is h-divide (when this occurs, the read and write heads will surround the portion of memory to be split off as the offspring's genome). If not, then we need to keep going. Skip the next instruction and move on to the mov-head which will move the head specified by the nop that follows (in this case nop-A which is the Instruction Pointer) to the Flow-Head at the beginning of the copy loop.

This process will continue until all of the lines of code have been copies, and an offspring is born.

An example logic gene

Here is a short example program to demonstrate one way for an organism to perform the "OR" logic operation. This time I'm only going to show the contents of the registers after each command because the functionality of the individual instructions should be clear, and the logic itself won't be helped much by a line-by-line explanation in English.

Line # Instruction AX BX CX Stack Output

1 IO ? X ? ? ?

2 push ? X ? X, ?

3 pop ? X X ?

4 nop-C

5 nand ~X X X ?

6 nop-A

7 IO ~X Y X ? X

8 push ~X Y X Y, ?

9 pop ~X Y Y ?

10 nop-C

11 nand ~X ~Y Y ?

12 swap Y ~Y ~X ?

13 nop-C

!NOOP

Because critical data must reside in critical blocks and non-critical blocks should not contain critical data prior to halting the system clock, a method is required to "flush" the pipeline of system 100 prior to sleeping. When a sleep cycle is initiated, all of the central processing units in the system begin to execute NOP's (no operation commands) repetitively until the pipeline of 100 is flushed. The critical blocks will therefore contain data which must be retained until 100 resumes execution of instruction. A NOP consumes one instruction cycle and causes a CPU to not modify any data in system 100. However, data contained in intermediate stage registers will be processed normally through system 100. This data will be allowed to propagate throughout the system until critical data has reached critical blocks. NOP commands will then reside in the intermediate stage pipeline registers. Because the non-critical blocks are implemented in dynamic logic (which includes the pipeline registers), when the system clock is halted, the pipeline registers will go to an indeterminant state. Because these registers contain NOP data only, this has no effect on restarting system 100. A more detailed description of the process of halting and resuming execution of instructions by computer 100 is shown in FIGS. 4a and 4b.

Process 400 shown in FIG. 4a ensures that the pipeline is adequately flushed prior to stopping the system clock of processor 100 and initiating a "sleep.". It should be noted that 400 is used in a three-stage pipelined architecture such as 100 shown in FIG. 1, and it may not be appropriate for another system having more or less than three stages of pipelines or one which has the pipeline structured in a different way. It will be apparent, however, to one skilled in the art that processes 400 and 450 in FIGS. 4a and 4b may be modified for use in other systems having pipelined architectures with different numbers and/or arrangements of stages. 400 in FIG. 4a initiates the "sleep" at step 401. The initiate "sleep" command is issued by stop controls 117 in FIG. 1. The appropriate command may be issued by stop controls 117 when a flag or a register goes to a predefined state or when a specific period of time has elapsed since the last "sleep" cycle. Stop controls 117 may include a timer to allow this to occur. Of course, a "sleep" may be initiated by another event (or lack of an event), such as user input, or the triggering of an external device. A variety of ways to initiate the sleep are contemplated within the spirit and scope of this invention. The charge in stop controls 117 is detected by instruction decode and control block 101. Once an initiate "sleep" command is issued to instruction decode and control block 101, system 100 prevents the loading of the flag registers 116 at step 402. This ensures that flag registers 116, which contain status information, are not modified in any way prior to stopping the system clock. Then, one NOP (no operation) command is executed by the CPU now processing the first stage pipeline registers. Critical data formerly contained in the stage one registers 110a-110d moves to the stage two registers 113a-113b at step 403. At step 404, count registers 104 are then prevented from receiving new data. This ensures that instruction execution resumes at the proper stage in the instruction cycle for the data now contained in stage two registers 113a and 113b. At step 405, one more NOP is fed into the pipeline and an instruction cycle is executed, to transfer the data in the stage two registers 113a and 113b to stage three registers 114a and 114b. Data which was in the first stage pipeline registers when the sleep was initiated should now be stored in the critical blocks 106-109, and thus will be retained for as long as the "sleep" takes place. At step 406, CPU general purpose registers 109 and memories 106 and 108 are prevented from receiving new data. This ensures that GP registers 109, RAM memory 108 and memory mapped I/O 106 retain data corresponding with the last non-NOP command executed prior to initiating the "sleep." Then, at step 407, the third NOP cycle is executed. Once this has been done, three NOP's have been executed (one for each processor), thus flushing the pipeline and critical data is retained in critical blocks.

The first, second and third stage registers in system 100 now contain non-critical data. The system clock may then be halted allowing data in these non-critical intermediate stage pipeline registers to go to an indeterminant state. This is satisfactory because all the data which is required to restart the system now resides in critical blocks 106-109, 116, 117, 101c, 102, 103, and 104. Normal system operation may resume in the place where execution was suspended at any time once a "wake-up" signal is issued. Therefore, process 400 terminates by stopping the system clock, and sleeping at step 408. System 100 stays asleep until a "wake-up" command has been issued by stop controls 117 as detected at step 409. All critical blocks in system 100 now are in a determinant state, and will remain that way as long as system power is not lost during the sleep.

The pipeline in system 100 may be refilled with data and recommance normal operation when a "wake-up" is issued. The sleep may last any period of time, as long as system power continues. As a result of the architecture of 100, space, complexity, cost, and power consumption requirements are all maximized. The present architecture and methods have equal application in situations where certain minimum clock frequencies cannot be maintained.

A "wake-up" sequence is shown as process 450 in FIG. 4b. Again, as discussed with the initiate "sleep" shown in FIG. 4a, an initiate "wake-up" is issued by stop controls 117. As discussed previously, stop controls 117 may comprise a timer or other device to cause a "sleep" on predetermined intervals or events. Many "wake-up" conditions are contemplated within the spirit and scope of this invention. The "wake-up" command is detected in process 400 of FIG. 4a, wherein 409 will branch to 410 in FIG. 4b. Once a "wake-up" command is detected, process 450 commences wherein one NOP cycle will be executed at step 410. Step 411 determines whether the pipeline has been flushed. 410 and 411 are executed until the pipeline is completely flushed of indeterminant data (data which was in the pipeline before the sleep). Once complete, step 411 proceeds to step 412 which now permits loading of the flag registers 116 shown in FIG. 1. Then, one instruction cycle is executed at step 413, wherein information is loaded from critical blocks 106-109 into the first stage registers 110a-110d. Then, at step 414, the loading of count registers 104 is now unblocked. Instruction cycle counting may resume. This resumes instruction execution in the last cycle where the last instruction (according to the instruction registers 103) was suspended. At step 415, another instruction is executed allowing the data currently residing in the stage one registers 110a-110d to be passed along to the stage two registers 113a and 113b. Then, loading of general purpose registers 109, RAM memory 108 and memory mapped I/O area 106 are permitted at step 416. One more instruction cycle is then executed at step 417 in order to load the stage three registers 114a and 114b with the data which would have been in them had the "sleep" not been initiated in process 400. In other words, data which was contained in the stage one registers 110a-110d will cycle through the pipeline until data has been now reloaded into the stage three registers 114a and 114b. Normal operation of system 100 may now resume at step 418. Process 450 ensures that critical data has been retrieved from critical blocks such as 106-109 and cycled through the pipeline to the same state that system 100 was in prior to sleeping. Therefore, instruction execution resumes at the same place where it was suspended.

Given architecture 100 shown in FIG. 1, it is necessary to use techniques similar to those shown in FIGS. 4a and 4b in order to properly stop the system clock and preserve the integrity of critical data which was formerly in the pipeline. Process 400 set forth in FIG. 4a ensures that critical data is put into critical blocks prior to halting the system clock. In addition, process 450 set forth in FIG. 4b ensures that the pipeline is filled with critical data prior to resuming instruction execution and restarting the system clock. Other methods may be used in a system comprised of a combination of dynamic and static logic, and which ensures critical data is in the pipeline prior to resuming operation. These other methods are contemplated within the spirit and scope of this invention. Of course, alternative structures for a computer may be used such as implementing the entire computer architecture in static logic. A computer implemented entirely in static logic does not require flushing and refilling the pipeline as set forth in FIGS. 4a and 4b, because the entire system will retain its data even when the clock is stopped. Data will be retained in intermediate stage pipeline registers in this embodiment, however, space, cost and size constraints may limit its application. The preferred embodiment maximizes these these goals, while minimizing power consumption.

Another alternative embodiment of the present invention is shown in FIG. 3 as 300. 300 has a similar architecture to that shown in 100 wherein certain critical blocks of the system are implemented in static logic, shown shaded in FIG. 3. Other major system components are implemented in dynamic logic to conserve space and reduce the cost of system 300. Because 300 uses a mixture of dynamic and static logic, as with 100, processes similar to 400 and 450 must be executed in order to halt and restart the system clock. This ensures that valid instructions and/or data only is present in the pipeline. These processes will be discussed with reference to FIGS. 5a and 5b.

As discussed with reference to FIG. 1, an initiate sleep operation will be issued by stop controls 317 to instruction decode and control block 301. As discussed previously, stop controls 317 may be operative upon activation of a timer or other device. In process 500 shown in FIG. 5a, the "initiate sleep" command 501 is detected, and step 502 is performed which prevents the loading of the flag registers 317 in architecture 300. This prevents any status conditions from being changed. One NOP command is performed at step 503 cycling through the data which may currently reside in the stage one registers 310a-310c to the stage two registers 313a-313c. Then, the instruction cycle count registers 304a-304c, memory mapped I/O area 306 and RAM memory 308 are prevented from receiving new data at step 504. Instruction count registers 304a-304c are prevented from loading because, when execution resumes, the instructions should continue at the appropriate phase in instruction execution. Memories 306 and 308 are protected to ensure that valid instructions are preserved. At step 505 one more NOP is executed in order to cycle critical data in the pipeline from the stage two registers 313a-313c to the stage three registers 314a-314c. Loading of general purpose registers 309 is then prevented at step 506. Again, because CPU general purpose registers 309 are a critical block, their loading should be prevented to allow restart of processor execution at a determinant state. Finally, one additional NOP instruction is executed at step 507. At this time, all critical data has been stored in critical blocks such as CPU general purpose registers 309, flag registers 317, or either of the storage memories 306 or 308. Once this last operation has been performed, the system clock may be halted, and the system sleeps at step 508, minimizing power consumption in architecture 300. Sleep continues at steps 508 and 509 until the "wake-up" is initiated by stop controls 317. Because store controls 301c, instruction registers 303, CPU select controls 302, count registers 304, general purpose registers 309, flag registers 317, memory mapped I/O storage 306, and RAM memory 308 are all implemented in static logic, architecture 300 will retain the data contained in those critical blocks until such time as the system clock is restarted and architecture 300 resumes instruction execution.

As discussed with reference to FIG. 1, process 550 is executed prior to resuming operation in system 300. Once a "wake-up" is detected from stop controls 317 at step 509 in FIG. 5a, process 500 proceeds to 550 in FIG. 5b. This process places the system in a determinant state into which normal processor execution may resume. Steps 510 and 511 are performed in order to make sure that the pipeline has been adequately flushed prior to permitting loading of various critical blocks in the system. Once this has been done, the loading of critical blocks may then resume. Step 510 executes NOP commands until the pipeline has been completely flushed. Once this has been done, step 511 leads to step 512 which permits the loading of flag registers 317. An additional NOP is executed at step 513 in order to allow information contained in the critical blocks to be passed along to the stage one pipeline registers 310a-310c. The loading of the count registers is permitted at step 514 so that normal processor execution may resume at the proper place in the instruction cycle. The loading of RAM memory 308 and memory mapped I/O area 306 is permitted at this time also. An additional NOP cycle is performed at step 515 allowing the loading of the stage two pipeline registers 313a-313c. Finally, the loading of general purpose registers 309 is permitted at step 516, and one additional instruction cycle is executed in order to allow the final stage stage three registers 314a-314c to contain critical data at step 517. Normal operation of system 300 may then resume at step 518. By executing the steps set forth in process 550 of FIG. 5b, data which was stored in critical blocks has been allowed sufficient time to propagate through the pipeline of architecture 300. Thus, valid data resides in the entire pipeline and execution may resume at the same place where the clock was stopped.

Link to comment
Share on other sites

  • 0

that was the longest post ive ever seen on neowin :blink: fortunately, you didnt write it (hopefully)..

on topic: i doubt youll be able to get it to run any faster.. the team that wrote the patch knows the main code they were writing the patch for inside out.. im sure they did it so its as fast as possible

Link to comment
Share on other sites

  • 0

WTF? I didn't understand most of that ****. As far as I know, on an x86 CPU, a nop is an alias for the instruction "xchg ax, ax" which basically does nothing (exchanging a register with itself is not very useful).

Link to comment
Share on other sites

  • 0
*long post*

For those who chose not to read this pointless long post.. he just confirms what gameguy said.

It's not a secret, NOOP performs no action and uses up 1 cpu cycle.

It is something crackers sometimes use to alter a programs execution path in hopes of bypassing or totally eliminating a critical part of the code that disables/prevents/hides something.

Link to comment
Share on other sites

  • 0
your 136 were totaly pointless , go stink somewhere else.

it does take one cpu cycle and it does not that was the point.

he was partly right.

That's cute.. flaming me.

NOP - No Operation (90h)

        Usage:  NOP

        Modifies flags: None

        This is a do nothing instruction.  It results in occupation of both

        space and time and is most useful for patching code segments.

        (This is the original XCHG AL,AL instruction)

                                Clocks                Size

        Operands        808x  286  386  486          Bytes

        none              3    3    3    1            1

        90 NOP No operation

On 486 and better, it takes EXACTLY 1 clock cycle, no less, no more.

This is taken straight out of the MASM help file, which I fully trust.

Link to comment
Share on other sites

  • 0
well you guys just when wayyyyyyy off topic on that one, but i guess it cant be done thanx for the help guys

No-one said it couldn't be done. You have to isolate the code which makes your game slower (most likely a timed loop) and fill it with nop's. Also, you need to make sure that the code you're disabling doesn't do anything other than slow the game down.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.