| |
Burglar
Registered: Dec 2004
Posts: 1090 |
Event id #2314 : C64 Cracking Competition 2015
Howdy Crackers!
These days the cracking scene is pretty active, but it seems most effort is spent on rushing out a version first with non-protected games.
Now that we found this nice original that hasn't been cracked, we thought, let's turn it around. Have a cracking competition with all of you with a full price EA game, including a nice protection. So here we go with the first C64 Cracking Competition 2015!
You are invited to crack "Return of Heracles" (C) 1983-1986 Electronic Arts.
Download the original here: http://sh.scs-trc.net/return_of_heracles.d64
Please read the rules carefully, and take all the time you need, quality over speed please :)
Rules:
- Submit your entry before or at 23:59 saturdayevening the 28th of March 2015 by email to c64crackingcompetition@hushmail.com
- Your release must fully run on a stock c64 + 1541.
- Your release must be filecopieable and packed.
- Your release must contain a crack intro, but you also must provide an introless version. This will be used to accurately measure size.
- Recracking is strictly forbidden, you must crack the original we provide. When in doubt, we will dig through your release and ask a few questions to confirm you really cracked it yourself.
- Individuals may only be part of a single release, so a group may enter multiple cracks, provided they are done by other members.
- You are allowed to use whatever tools you want.
Calculating Results:
50% of the result will be determined by public voting, either using or own voting system or on csdb. Stay tuned for additional info.
The other 50% of the result is calculated by the compo organizers using the following criteria:
- The shorter the better *)
- The faster it loads the better
- Proper saving capabilities
- Full PAL/NTSC compatibility
- Amount of bugfixes (if any bugs present in game)
- Amount of trainers (no double trainers)
- Minus points if you introduce bugs and need multiple versions
- The more devices besides 1541 (or compatible) you support, the better
- Optional REU support is also nice
*) We explicitly do not want to discourage the use of large intros, hence
the introless version requirement.
Most of all, have fun cracking this full price game!
The Organizers,
Peacemaker/Hitmen
Burglar/SCS*TRC |
|
... 158 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Is there a rule about bonus points for IFFL? Haven't found such a thing. Anyhow, "real" IFFL would also probably mean smaller size, so i think there would be no need to judge "real" vs. crappy IFFL. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
you'll have a hard time making a crack of this game that doesnt use (some form of) IFFL anyway =P |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
IFFL isn't != filecopieable?
Isn't this breaking a rule? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
hu? the whole point of IFFL is making it filecopyable |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
I thought the whole point was mitigating sector overhead, saving 127 bytes per file on average. :)
But yeah, any form of IFFL which is not file copyable (= comes without scanning) is broken badly. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
well, saving on size is only a side effect - the first IFFL systems just linked all the sectors into one big chain, leaving the gaps - however, its the only way to make it filecopyable when you have more small "files" than you could put into the directory. which may or may not be the case with this particular game as well =P |
| |
MagerValp
Registered: Dec 2001
Posts: 1075 |
Quoting BacchusWhat is the current preference?
A fastloader that supports as many devices as possible, with kernal fallback for everything else. |
| |
Maxlide
Registered: Apr 2003
Posts: 31 |
Peacemaker and Burglar are the organizers of this compo and maybe these both should cause for clarity. |
| |
Burglar
Registered: Dec 2004
Posts: 1090 |
I'd say the rules and criteria we set up are quite clear, complete and to the point.
if not, gimme a shout :)
personally, I wouldn't do a multi-device loader, simply because I never built any. This would give me less points than the version that does support many devices, but so be it ;) I'd rather beat someone in size instead. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
My IFFL routine only supports 1541/1571 anyway. My issue then would be that the IFFL I have will not allow saving, and that's an integral part of the game to be able to do that. So I'm out of luck using my IFFL unless I rewrite it.
But F*CK what a mess this loader is.
Normally the game calls the loader with filename/number in A and then you can just replicate the loader so that calling the loader with a value in A you load that very file.
Now there is calling the loader with a number of different values. The part at $FC3E is difficult enough but when it's also called repeatedly from $85xx and stuff is moved around in memory I get mad.
Does it load blocks to $FB3E, and move it to $1700 whereafter the routine under $8500 moves it to another location or what the f*ck is happening here? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ... | 17 - Next |
