This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Zemmargorp
1
« on: October 23, 2014, 10:12:56 am »
I'll try the editor when I have some time. 
Thank you Then you should use the version of the editor I'm currently working on (link below). I've improved a bit the first version. I made some little bug-fixes and minor changes, and added the ability to resize levels ! Before, they had to be of size 20x16. As I didn't write any documentation on how it works now, I'm gonna write it here because it's not very clear in the program : - The editor requires VB6FR.DLL and MSVBVM60.DLL to run. - Before starting making levels, you absolutely need to do "File -> New", or the program will be locked. - When you edit a level, there's a toolbar with every item of the game (air, ground, diamonds, boulders, walls, player, monsters, ...) plus two other tools, at the bottom of the toolbar. The second one doesn't do anything for now, and the first one (which looks like an array) serves to resize a level. Select it, and then move the mouse over the level : when a green line appears, click to insert a new column, and when a red rectangle appears, click to remove the column highlighted. Hold on CTRL to use it for the rows. - Don't forget levels must be at least 12x8, and shouldn't contains more than 768 boxes (768 because of L 1, L 3, and L 6's size), otherwise, the editor will refuse to resize the level. Also, you won't be able to put more than 30 enemies. - To see how it works, you can also try to edit levels I've already made (they're in the zip). Have fun !
2
« on: October 16, 2014, 01:12:32 pm »
+1 and download
'nuff said.
Well, thank you very much ! I hope this program will be useful for you.
3
« on: October 13, 2014, 01:31:05 pm »
6 downloads so far ! That's quite good ! I'm happy people download it (by the way, they probably like this too, and thanks to ClrDraw for his +1), because I spent so much time working on this ! When I think I first made it in TI-Basic because I didn't know how to use floating numbers in Axe, and then I decided to make it in Axe to make it faster and learned some assembly commands for the OS's floats...
4
« on: October 13, 2014, 01:30:52 pm »
Now working back on the level editor. (I'll work on the game later, if I have the time.) You can find the first version here, which I'm improving on some points. Here's my current todo list : - improve GUI (want a more user-friendly one)
- hunt bugs (hopefully, they are very rare)
- add the ability to resize levels
- make a ZIP game+editor+levels+readme
- any other idea ?
20 downloads of the game so far ! Great !
5
« on: October 13, 2014, 01:10:23 pm »
That command definitely makes sense to add. The only thing I'd think about is if there's potentially a token that makes more sense, but none spring to mind.
Well, I don't have any other idea either, but this one seems fine to me... Using the RecallGDB token would put the DirtyGDB instruction close to StorePic, RecallPic, and StoreLCD  , so it's good for programs which use graphics commands. (Otherwise it would also be possible to use DispTable which is just next to DispGraph, but this one is less logical.)By the way, do you know if there are other cases where Axe instructions can cause some minor issues (but easy to fix) with the calculator's OS ? I thought of this one because I often use the graph screen in my programs, but there may be other cases similar to this one.
6
« on: October 11, 2014, 11:21:06 am »
Symbolic and PrettyPrint works pretty well on a 83+, as they were made before the 84+ even existed.
I've tried them, and they are great apps, but they require a bit more than 5555 bytes !
7
« on: October 11, 2014, 10:26:19 am »
Oh I meant that DCS and Mirage erases the game graphics from the screen upon exiting.
I doubt they really mark the graph screen as dirty... Do you know what they exactly do ? Clearing the current display and/or the text screen ? Clearing the graph screen ? Mark it dirty ? EDIT : I tried with MirageOS, and just remembered the app itself uses the PlotSScreen area, so indeed, it marks it dirty, whether the program uses it or not ! The downside or compiling your sources for a shell is that you need it shell the program. And if someone uses your program with a Mirage-compatible shell which does not mark the graph screen dirty, then compiling it for MirageOS was a bit useless ! However, people would better add a DirtyGDB instruction to programs that uses the graph screen instead of compiling it for any shell : adding this instruction will only add a few bytes to the compiled program, which won't require any dependency, whereas compiling it for MirageOS adds 37 bytes for the program header, and the shell is required to shell the program !
8
« on: October 09, 2014, 01:23:49 pm »
I am unsure if those are really Axe issues, because they are present in ASM too if you aren't exiting from your programs properly, not to mention that some people use such program as sub-routines and might not be willing to see the program clear the graph screen background image for them. I think that for that reason, it is generally assumed that it's the programmer's job to prevent such issues from happening.
I think that making the program require a shell usually helps in certain situations, though.
Well, indeed, they aren't Axe issues, almost all assembly programs using graphics mess the PlotSScreen memory area (unless they use another memory location, but that's hardly ever the case). But Axe can include a way to fix it. As you said, it's the programmer's job to prevent this kind of problems from happening, so in the example I made, he would use the DirtyGDB command in Axe, and Axe Parser would add the compiled instruction "mark graph screen dirty" to the compiled program. So when the user comes back to the OS, the full graph will be redrawn, and there'd be no problem such as the cursor moving on the last picture displayed by the program instead of the curve which was drawn before. However, if he doesn't want the compiled program to mark the screen dirty (because he used the drawing functions in a sub-program), then he should just not use the DirtyGDB command. I don't see what the problem is  , and I'm not sure to have fully understood what you mean, especially your last sentence. Sorry  .
9
« on: October 08, 2014, 10:46:29 am »
I was wondering if it would be interesting to do changes in some Axe functions to avoid as much as possible minor problems with the OS. For instance, when I use drawing functions, the graph is not marked dirty, so when after exiting the program I use the graph the curves drawn are mixed with the program's picture.
As, for a lot of reasons, Axe wouldn't be able to determine if the buffer is without fail changed during the program's execution (unless it would add a "mark graph dirty" after each drawing instruction, which is not a good idea), then why not adding a command which would mark the graph dirty ? Maybe rename a token like RecallGDB (which is not used yet) "DirtyGDB".
There might be other small "compatibility issues" like this one with the OS, but I don't have any other example.
11
« on: October 07, 2014, 12:58:53 pm »
EDIT : Oops ! Message posted in the wrong topic. Admins, you can remove this post.
12
« on: October 04, 2014, 11:16:33 am »
Wow, that's very nice ! What a shame most programs are never finished...
Yes, 2003 seems a bit old to me... When I think that VB1 was created in 1991 !
13
« on: October 02, 2014, 01:41:18 pm »
Actually to clarify, I last used VB6 back in Early 2003. I just used it two years. Sadly I don't remember if I have the source anywhere anymore, so they are executables and the games are low-quality because they were made in a very short period of time as school projects (except the last one which was made as side project in 20 minutes) and my only programming experience was TI-83+ BASIC back then.
Illusiat 5 PC version
The Reign of Legends 0
WARNING: EPILEPSY! Avions
Illusiat 5 and ROL0 only runs on Windows 98, 2000 and XP, because I never could get the required dependencies (DAXCTLE.OCX and ANIGIF.OCX, which are not included) to run under 64-bit Windows 7. Even Virtual PC can't run ANIGIF.OCX
[...]
Had I gotten my own computer in 2003, The Reign of Legends 0 would have been expanded into a full RPG.
2003 ! That's quite old to me... I was only 5, and I didn't know VB6 yet ! I'll try them when I have time. Thank you for the links (and the videos).
14
« on: October 02, 2014, 01:37:57 pm »
EDIT: Nvm I was on the wrong topic page >.<
Anyway I'm gonna download this now so I can try it later.
Thanks ! If you make interesting levels, please share them ! I'll be glad to try levels I haven't created !
15
« on: October 01, 2014, 12:35:10 pm »
Yeah I thought it could be that, because I remember that certain programming languages, such as TI-BASIC and Visual Basic 6, were entirely dependent on computer speed, so if you made a game on a 300 MHz computer it would be totally unplayable on newer machines. Just try one of the VB games in Omnimaga archives to see what I mean, but mind the seizures.
Did I read "Visual Basic 6" ? My favorite programming language ! So it hasn't completely sink into oblivion... Where can I find the VB games from Omnimaga archives ? And are their source code also available ? By the way, I've made BOULDASH's level editor in VB6 .
|
Show Posts
