I have some untested code that prepares objects for drawing (find eligible candidates, sort by distance). If it works correctly, then all you need is to implement the rendering code which should be straight-forward.

There's no ld b,(addr) command. You can do ld bc,(addr-1) if you want (puts (addr-1) into c, (addr) into b). Otherwise, you generally do ld a,(addr) \ ld b,a. Not that ld bc/de/sp,(addr) are prefixed instructions and thus take an extra byte (4 bytes total) and 4 cycles (20 total). ld hl,(addr) is not prefixed so it's slightly faster and smaller, though i think you can use the same prefix as with bc/de ($ED) and it'll still work the same. Don't know why you'd wanna do that, though.

New font to the project page. http://clrhome.org/slender. Also changed logo from Slender, to Slender-TI to distinguish it from the original, both so my project has a distinct name and to avoid copyright issues.

A few changes to the source code to try to find this bug and still it persists. It crashes immediately after the splash screen (pressing 2nd). I'm toying with the idea that it may be the keypress itself that is crashing it (somehow the value of a is getting distorted during the keypresses, but i added some push/pop af and it persists. My second thought is that its somewhere in my object rendering loop, and since I'm still pending a sorting algorithm, it seems pointless to debug that at this point.

Finally resolved the Slender crash. Turns out if I'm activating a second keygroup, I need to reset the driver. Well, lesson learned. Currently waiting on a sorting revision to my rendering code and 2 & 1/2 sprites. Then, we can have a release.

A bit of restructuring of the slender repository. Files renamed, consolidated, folders renamed to more explanative things. Main game loop moved into main file. Support for multiple keypresses at once added. This allows you to do things like walk and collect a page, or turn while walking, but it also allows you to do dumb things like turn both ways, and walk back and forth at the same time. Also streamlined and fixed the filtering of objects into a stack of objects on screen, so still have the by-distance sorter to do. Still have 2 sprites left to do. User's Guide is in progress.

Also, I asked this in another topic, but I'll post it here since it technically belongs here. There is a header somewhere for a shell that supports no-stub. I thought it was Mirage, but was told that it was Ion. Is there documentation for this? And if the header is, for example, an Ion header, will it work for DCS, and will it also work if no shell at all is present?

Also, I asked this in another topic, but I'll post it here since it technically belongs here. There is a header somewhere for a shell that supports no-stub. I thought it was Mirage, but was told that it was Ion. Is there documentation for this? And if the header is, for example, an Ion header, will it work for DCS, and will it also work if no shell at all is present?

By choosing between ret and xor a at the beginning of your program, you can choose if it will work when it's run without a shell. DCS supports both of these types of Ion headers and will display the description when one is present.

Yeah, you just need to change the ret to xor a. You don't even need to put a description, a .db 0 would probably be enough for shells like Mirage and DoorsCS to handle it. It will work with any recent shell or without a shell, as long as you don't use any ion libraries. Also, keep in mind that nostub programs are much more limited than non-shell programs because the OS limits them to 8kb. It'll refuse to run the program if it's too large, so you'll need to run it with a shell or write a launcher that copies itself to saferam and then copies your program to 9D95 and deletes it afterwards. You'd have to handle program writeback yourself, though.

With the return to progress on this game comes another redesign of the project page at http://clrhome.org/slender. Also comes substantial progress-- completed saving/loading, keypress detection, movement, looking, death conditions, assorted math routines, a raycaster and frame rendering (by Zeda). All that is left is one part of the frame rendering, sprites, and the map, and then we are finished.

ps: no screenshots yet bc i made the incredible choice of doing the rendering last :p

While I've been working on Star Trek MP for the CE, I decided to give my Slender CE project a bit of a nudge in the "complete" direction, by tossing in a ported version of Star Trek's rendering engine and modifying the mapdata structures a bit. I was inspired to do this bc of the upcoming release of an official Slenderman movie.

I built and created a working program, but the renderer is a little... off. Firstly, you seem to only see one tree, nothing else. Looking around (left/right) works properly but moving forward or backward does not. Regardless of what direction you're moving in you seem to move away and then towards. I wonder if this is an issue with my rendering algorithm or my map generation algorithm, or possibly because you're overflowing the range quickly.

This game is still in progress, but I'm having a weird and frustrating issue. The rendering engine seems to render only the Slender sprite and one of the other sprites. I'm wondering if this is actually an issue with the spawning algorithm instead. I've tried re-writing, checking data types etc, but cant figure this out.

Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.