| |
JackAsser
Registered: Jun 2002 Posts: 1989 |
Eye of the Beholder
Resumed. Easy Flash.
https://youtu.be/dvWrimZUk40 |
|
... 259 posts hidden. Click here to view all posts.... |
| |
cadaver
Registered: Feb 2002 Posts: 1153 |
Much respect, the data wrangling, level scripting and UI interface code involved certainly add up complexity. I'm suprised how well the bitmap graphics work without colorclashing like hell. |
| |
Oswald
Registered: Apr 2002 Posts: 5017 |
Quote: That depends on how you define complex. A good platformer such as Turrican is imo alot harder to implement given real time requierments, full screen scrolling, stable multiplexer, complex IRQs. This game has nothing of that, it’s just a lot of, uncomplicated, code.
yeah, but all that code fits easily on the back of a stamp compared to what I think you have here. and certainly doable on a vanilla c64, unlike your effort which would be a suicide. |
| |
JackAsser
Registered: Jun 2002 Posts: 1989 |
Quote: Much respect, the data wrangling, level scripting and UI interface code involved certainly add up complexity. I'm suprised how well the bitmap graphics work without colorclashing like hell.
Bitmap with sprite overlay. Chars not 100% solid, i.e edges on items and monsters uses the sprite layer. Fullt opaque chars are in plain mc bitmap |
| |
JackAsser
Registered: Jun 2002 Posts: 1989 |
Quote: yeah, but all that code fits easily on the back of a stamp compared to what I think you have here. and certainly doable on a vanilla c64, unlike your effort which would be a suicide.
Nah, it’s just 29k lines (hand written) of asm so far. ;) |
| |
Oswald
Registered: Apr 2002 Posts: 5017 |
jesus christ, I dont have so much in p1 src, which is a bloated vb6 shit :) |
| |
Oswald
Registered: Apr 2002 Posts: 5017 |
how do you manage to handle the huge code size ? breaking it down into bigger chunks, oop like thinking? |
| |
JackAsser
Registered: Jun 2002 Posts: 1989 |
Quote: how do you manage to handle the huge code size ? breaking it down into bigger chunks, oop like thinking?
Like any big project. Separation of concerns. Proper segments. Bank-agnostic jsr-macros that automatically bank switch when needed etc etc. Strict calling conventions between routines. Proper event driven main loop to avoid concurrency issues (i.e. classic UI coding). But even with all that there sneaks in hard to get bugs, mostly because I accidently reuse ZP-vars as loop vars and then two routines are connected and the other messes with the loop index in the former. Totally annoying but I don’t want to waste new ZP per sub routine since it’s a scarse resource. |
| |
HCL
Registered: Feb 2003 Posts: 716 |
Unbelievable!! |
| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
I already commented on the FB post, but I got to say it again - amazing!
How are you implementing all the rules/game-logic? Is the original game reverse-engineered so you have something to work from?
And the bitmap+sprite overlay does a splendid job with the graphics, nice to see what can be done when 50 fps isn't a requirement! |
| |
JackAsser
Registered: Jun 2002 Posts: 1989 |
Quote: I already commented on the FB post, but I got to say it again - amazing!
How are you implementing all the rules/game-logic? Is the original game reverse-engineered so you have something to work from?
And the bitmap+sprite overlay does a splendid job with the graphics, nice to see what can be done when 50 fps isn't a requirement!
I spent 4 months in IDA Pro disassembler disassembling the DOS version and reimplemented it in Java and iOS. Years later ScummVM did the same so it’s a good reference to double check when I find my own sources weird. Though most often in those cases it has been bugs in the original. |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 28 - Next |