I tried it, but unfortunately the graphics doesn't work in Wine. You can't see the background nor the characters, but you could see the HUD.
I still managed to win a game despite seeing absolutely nothing lol.
It's working fine for me with Wine 1.5.7, try updating Wine to a newer development version and update your video card drivers (especially if you have NVidia). The only problem I'm having is the old netplay end bug from Soku, where if you exit a network match, the game freezes and has to be terminated manually (it can sometimes lock up your whole system if it's in full screen, so keep that in mind when playing online).
And yeah, the AI seems to be even more ridiculously easy than it was in Touhou 12.3...
Anyway, I'm having quite a lot of fun with the game and, of course, greatly enjoying the few pieces of music it's offering. ^^ Can't wait for the full release!
now, I haven't looked through the code yet, and I wasn't really able to figure out how to play this (didn't know how to kill zombies). It would probably help if you explained the relevant variables and buffers in the code segment, such as I, U, G, θ and r1, among others. However, I already have a theory about this, though I might be wrong:
I have had a similar problem with a project of my own previously, and assuming the enemies freeze the moment another one gets killed, you might be doing something wrong in the code that removes enemies from the buffer when they get killed. An enemy "freezing" could have several causes: forgetting to erase an enemy from the screen buffer, or incorrectly/not moving backwards the remaining enemy entries in the buffer when one is removed (in my case it was the latter, causing enemies to turn invisible and randomly freeze and warp around when one was killed).
For debugging purposes, you could try outputting the buffer index of an enemy when you kill it, and check if the problem only occurs on enemies with a certain index, so you can narrow down the randomness of a "sometimes-occuring" bug to specific criteria that must be met to reproduce the problem.
Best of luck with debugging your project, ~ defmenge
This looks like a nice program, I've been collecting legal Minecraft's jars (with and without various mods) since 1.5. The download link appears to be broken though, due to an ellipsis being inserted into it. I most likely wouldn't be able to use it anyway since it looks like a Windows-only program and I'm using Linux.
First time I see this topic. Hmm interesting concept. I like the look as well. I haven't got time to try it but from the screenshots it looks pretty fun to play
Thanks for the feedback, though the concept isn't mine, this game is a calc clone of DROD; I did make the sprites and UI design myself though. I think I posted this topic just after you left Omnimaga for some time, which is why you didn't see it until I updated/bumped it.
Also, I will make it an app as I *will* need 16 KB, the compiled code is 6 KB already and I will have to compile into an app soon.
Instead of making it an app, you might be interested in Crabcake Axiom, written by Hot_Dog. It's a utility that allows you to create larger-than-8kb assembly programs (including Axe Parser)
I've heard of Crabcake, but as far as I know, the program still has to be in RAM to be executed (please correct me if I'm wrong about that ^^; ), and hold/level files will be rather large as the levels grow. Also, I remember reading MirageOS doesn't like Crabcake programs, and even though many people on Omnimaga seem to recommend using DoorsCS instead, I believe MOS is still the most widespread shell among most calc gamers.
Sorry about the lack of updates recently, I couldn't work on DROD for about a month due to Axe Parser being unstable (luckily no code got lost), and because I rewrote most of the code for Axe 1.x, I couldn't revert to an old version. Also, now I have to find back into my own confusing code, get familiar with all memory locations again etc.
What I've managed to do is to split DROD up into an editor app and a game app, and the map is now actually saved into the AppVar "DH Test" when you use the editor. Also, I've smoothened out roach movement a bit if there are lots of monsters in a room at once (later on this can be turned off in the settings). In addition, the roach queens' weird movement behaviour should be fixed now, they will now move as expected, and all roaches should now move if another one was killed in the same turn.
No screenshots this time, because not much has changed, really. The controls of the new editor are the same as the controls of the old integrated one: Arrows to move cursor, [Y=]-[GRAPH] to place tiles/monsters, DEL to clear the level, CLEAR to quit without saving, ENTER to save and quit.
New known bugs: Roach queens may randomly turn into roaches, not much is known about the bug.
'Doppelgänger' wird tatsächlich manchmal als englisches Wort benutzt (oft wird es auch als 'Doppelganger' geschrieben), ähnlich wie 'Kindergarten'. Es gibt eine ganze Reihe solcher Wörter: [wikipedia=de]Liste deutscher Wörter im Englischen[/wikipedia]
Ah okay, thanks. I've never worked with anything more low-level than Axe and I don't know much about how the TI-8x's flash memory works, so I was a bit confused between sectors, pages, swap memory and why APP sizes have to be multiples of 16 KB.
If the subprograms are in RAM, you can press PRGM to open the faulty program and it'll scroll to the line the error occured at. However, if you keep programs in the Archive (like I do), it'll just exit when you press PRGM, so it would indeed be nice if it displayed in which subprogram the error occured.
I'm not quite sure what these sector things are, but I guess you're talking about the bug that occurs after compiling which messes up the calc (or in this case, Wabbitemu), causes errors when sending files and clears the RAM after my app has executed until I restore an older saved state or clear the Archive. It would be nice if you could fix that, I'm currently having incompatibility problems with the room drawing routines (objects and the player disappear sometimes), which I can't fix if I have to restore an old save state after each compile.
Also, I found out that DROD8x outputs a lot of random garbage to the home screen whenever I load a room, even though there is not a single command for printing text inside the room loading code. Perhaps that's related to MathPrint, though I haven't had any problems with that in 0.5.3 and earlier.
Lbl LOA Copy(Y1+R,L1+150,144) sub(LDR,L1+150) .Random garbage occurs above this line sub(DRU) sub(DRR) If {L1+123}>0 For(I,0,{L1+123}-1) sub(DRO,I) End End 0->{L1+114}->{L1+115} 0->{S+34} sub(PSW) Return
Lbl LDR .r1: DATAPTR 0->{L1+123}->{S+186} Fill(S+186,288) For(J,0,11) For(I,0,11) If inData({J*12+r1+I},GDB1O)^(length(GDB1O)+1)!=0 {J*12+r1+I}->{{L1+123}*2+S+186} I->nib{{L1+123}*2+S+187*2} J->nib{{L1+123}*2+S+187*2+1} {L1+123}++ 0->{J*12+I+S+42} Else {J*12+r1+I}->{J*12+I+S+42} End End End sub(MSK) Return
Lbl MSK 0->{L1+150} Fill(L1+150,144) For(I,0,143) If inData({I+S+42},GDB1S)^(length(GDB1S)+1)!=0 1->{L1+I+150} End End For(I,0,min({L1+123}-1,287)) sub(OMK^^r,I,1) End Return
Thank you very much for adding support for single byte variables! This will be extremely useful to my current and probably all my future projects. Keep up the great work!
Show Posts
