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 - E37
Pages: 1 ... 3 4 [5] 6 7 ... 24
61
« on: November 02, 2020, 01:22:09 pm »
@E37 I know this is an old post but I was wondering what you did as an overall editing procedure. I'm making my own editing program but I don't know how to go about actually editing. Are you using a buffer and saving on the fly, or are you writing to the program directly?
I am wrote to the program directly. Or at least a temporary copy of it if it was archived. I didn't make an edit buffer because it was hard and didn't really matter unless the program was 15kb or larger. I know I posted the guts of an editor somewhere or other, you should look at that as it is a lot better done than this.
62
« on: October 01, 2020, 06:15:09 pm »
My 84+ SE gave 21845, 21845, 21845, 21845
63
« on: September 24, 2020, 09:38:28 am »
Hm. Im not really sure what you are trying to do here but Ill try to point out anything that could be a mistake. 1. I don't see Str1 declared anywhere. Since you said some of it worked I assume you declare it somewhere and just haven't shown it. 2. In you third code block, the if statement doesn't do anything unless you meant :strGet(Str1,A-1)-B to be :strGet(Str1,A-1)->B 3. In your first block of code you say :If inData(GDB1,getKey)->A I assume that you didn't actually use that code because you flipped the arguments for inData. Nitpicky Axe coding things and optimization: 1. You use :For(G,0,8) : <Body> : End From my experience, using that type of for loop is bad practice. Unless your for loop has a variable end amount (Like you had a variable instead of the using the single argument for loop is always faster, smaller and more reliable. For example :0->G:For( 8 ) : <Body> :G++:End 2. You don't need the colons on lines like "[window]"[00]:"[zoom]"[00]:"mode"[00]:"[del]"[00]:"[x^-1]"[00]:"[x^2]"[00] 3. Please put your data at the end of your code. Scrolling through a giant block of data in the middle of code isn't fun. 4. There is no real reason for GKY to be a subroutine. 5. Why are those text commands not in a loop? You could just do: 0->X:For( 8 ):Text(3,X++*2+1*3,strGet(Str1Menu,X-1)):End:[]->Str1Menu:"Edit"[00]"Lock"[00]"Arch"[00]"Cut"[00]"Copy"[00]"Paste"[00]"Rename"[00]"Folder"[00]
64
« on: September 15, 2020, 07:06:41 pm »
Did you ever get the Career mode fixed?
I uh, what? I don't recall ever having any serious bug with campaign mode assuming that is what you meant. But if it did exist, I fixed it as there aren't any bugs besides the small one that the credits don't always show when you win the campaign.
65
« on: September 09, 2020, 04:25:12 pm »
So I figured I might as well kinda necro this as I have stuff to show. I added 'dynamic' lighting. It basically adjusts the contrast based on how many units/buildings are close to the screen. Each object has its own brightness value and magma even has its own subtle glow. I turned on wallhacks for the demo so thats why everything looks strange. The whole recording is pretty low effort but eh, it shows the general idea. The transitions between light levels look way better on actual hardware (read: it doesn't have that super obvious flicker that the emulator does) Actually, come to think of it, the whole game looks way better on hardware but I guess that is true of every game. It can be disabled in the settings. The whole project is basically finished. All I need to do is find some time to figure out a minor bug on campaign completion and add descriptions to all the options in the settings menu. Not shown: lasers create light flashes when on or close to the screen. It can be disabled separately from the lighting if you find random flashes irritating.
I added a bunch of other cool things in the mean time too but I can't remember what they are...
66
« on: August 26, 2020, 12:09:14 pm »
So this isn't optimized or even tested, but this should work... I didn't use code formatting because for some reason that breaks superscripts.
#Axiom(MEMKIT) Return!If GetCalc(oOp1, Y1) .Get the pointer to the file in Op1 and return if it isn't found !If {Y1}r-EBB6D .Assembly programs have the header of 0xBB6D. I might have this reversed and it should be '!If {Y1}r-E6DBB' .Its an assembly program New(E9D95, 0, {Y1-2}r->X) .Make space in ram to copy the program to. I don't test to see if there is enough ram but New() should return 0 if it failed... Copy(Y1, E9D95, X) .Copy the program to 0x9D95 X:Asm(E5) .Save the size of memory that was created. Asm(E5) is Push HL Asm(CD(E9D95)) .Jump to the program like a subroutine Asm(E1)->X .Pop the saved value for the size of the program Delete(E9D95, 0, X) .Remove the memory we created.= Else .Its a basic program oOp1 Asm(EF(whatever the bcall is to run basic programs)) End
67
« on: June 09, 2020, 09:20:00 pm »
I posted this to Cemetech and now am here and will also on Codewalrus.
I would even propose calling TI's bluff on something. Write TI a letter, signed by a EVERY major calc development community - Cemetech, Omnimaga, Codewalrus (unity is important on this), informing them that if they do not revise their decision on C/asm, and implement exam security in a way that is conducive to teaching, learning, and doing programming, we the community will be designing, releasing and marketing our own calculator to compete with them. And if they do not walk it back.. actually follow through.
There is no action legally they could take to prevent this: it would be our own hardware and programming, no copying of names, symbols, anything. Free market, people can compete with whoever they want. What bluff? We don't make up enough of their customer base for them to care. Not to mention, we'd need to be competing with them in a space that they already have competition in (HP & Casio). We would need to get the calculator we create to be approved for use on standardized tests, which is not easy, or cheap.
If we would be able to make any threats it would be that we would circumvent test security. But since that is (likely) more possible with assembly and basic I don't see that we would have any leverage. Wouldn't our best option to be to hope for an exploit to make custom cracked OSes that allow assembly?
68
« on: May 10, 2020, 03:51:44 pm »
Could you use one buffer for the rectangles and just draw a line at the bottom of each rectangle every frame and not erase the previous one? All you would have to do then is draw 16-24ish horizontal lines each frame. (and do the bit of trig to figure out where it should be) You would need another buffer for the screen and another for double buffering but drawing the colored background then copying over the rectangles then drawing the ball should be very fast. All that probably isn't needed because it looks really smooth as it is. It was fun to think about though
69
« on: February 29, 2020, 04:24:44 pm »
If you know how big your inventory is going to be, you can use:
Buff(<size>)->var Where you insert the size and the variable. To access it use {var} and ->{var} to write. Add an r after it if you want to change a 2 byte value. As for text based, that has nothing to do with the inventory system.
What the code you mentioned is doing is taking the os variable named Str00 and copy-pasting its contents as data into the end of the program. He had meaningful data in Str00 but since you don't have any data to include, you don't need to use those statements.
70
« on: February 27, 2020, 10:55:10 am »
@E37 So what your saying is if I just coded the module in spasm-ng format then I can use the converter tool? That's what I did with the include file . I'm going to try using jsTIfied to make one using rorg because I don't always have access to a windows computer. Currently on Chromebook.
There are asmto8xv.exe and 8xetoasm.exe in mimas/tools I believe you just drag and drop files on them. There is no special spasm format, it just takes a text file with a .asm extension. Not sure what you meant for the include file, but I hope you found the tool on your own. The whole point I was trying to make is that you need to use rorg instead of org for mimas when using code from spasm.
71
« on: February 27, 2020, 10:13:26 am »
I guess Im late to the party as usual. Looking at the module code, I assume it is written for spasm. Mimas is kinda picky with moving addresses. RORG $ADDRESS should make it so that all following code will start at that address. This means that you should use RORG instead of ORG for Mimas. It also has tools for converting .asm files to its own appvar format (and back) for some easy copy and paste to and from the editor.
72
« on: January 30, 2020, 08:17:28 pm »
I found the edge cases the worst. There are so many different special scenarios that break your nice logic. Ignoring those, a program editor is quite easy to write. I could probably whip up a fully functional editor is 2 days if I didn't have those as a roadblock.
73
« on: January 29, 2020, 04:35:00 pm »
Also a question for the "pro's". Would it be possible to write a font hook that makes the whole OS run on small font? That would be quite entertaining and also very useful.
It would be quite difficult, probably. The font hooks only ask for the data and expect it to be in a specific format. I had to do some very convoluted things in Batlib to enable 8-pixel wide fonts. Basically, text drawn with the large font (that the OS naturally uses) is drawn only to the LCD and not to the graph screen, and the LCD supports a 6-bit and 8-bit mode.
It is doable, it would just be difficult.
You wouldn't get anything from it if you did. Unless you plan on rewriting all the os's menu code, it wouldn't show any more information than it normally would. It wouldn't have any idea what to do with the smaller font size. Large font is fixed size and the os makes a lot of assumptions based on that. The only other option is to make a custom font that makes the large characters look like the small ones. And all that would do is make a huge space between each of your characters. Zeda: Unless I completely misunderstood what nonstickatom is asking, I dont see how it would be doable. What do you mean?
74
« on: January 26, 2020, 07:27:42 pm »
So I have about 2 weeks more of interesting stuff to show off and have written the little description of each, but getting the recordings for each day is a little work. And by a little work I mean about 1-2 whole minutes. Still, it is so easy to push off making the posts. There is currently one boss enemy in the game, the Rocky Horror. He has a healthbar, and a bunch of specific animations and attacks. He is designed as a 'cavern ending' boss and is insanely tough. Without a crazily upgraded unit, the horror will tear through pretty much anything in its way. It is mostly there for players who have played past the end of the game and unlocked the superweapons and have a really overpowered team. (which will probably get slaughtered anyway > ) And yes, I have beaten it on Insane difficulty. But that is expected since it is my game... Also I know his feet are broken. And I have fixed it. I haven't updated the emulator's version of the game since I started this since it was a huge pain to get it to work at all...
75
« on: January 25, 2020, 02:50:49 pm »
Every unit (and almost every building) can be upgraded. There are 5 different options for units, 2 are only one level, but the other 3 can be upgraded many times (they each have different maximums). The more upgrades are applied, the more expensive they are up to a point. Buildings have 1-3 upgrades and their cost doesn't increase. Their upgrades have much smaller limits but are more powerful.
Pages: 1 ... 3 4 [5] 6 7 ... 24
|