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 - Quigibo
Pages: 1 ... 50 51 [52] 53 54 ... 135
766
« on: October 09, 2010, 04:25:29 pm »
You can write a program that takes an initial sprite and then rotates it 30 or 22.5 degrees each time and then exports the hex code for every rotation. It might be a little complicated to write, but speed isn't an issue since you're just pregenerating them. It would be a useful program for a lot of people actually. Maybe I should write one in Axe unless anyone else wants to give it a shot?
767
« on: October 09, 2010, 05:08:25 am »
Its mostly electrical terms. Like male and female connectors, wire strippers, tickler coil, screws, nuts, etc.
You don't "halve" a variable unless you can actually do it. If the variable has to hold more than 16 possible unique values then a nibble is not sufficiently large enough to hold your data so you would have to use a byte or word instead. Some tile mappers for instance might always use 16 or fewer tiles per room and so you can load a palette for each group of rooms and then compress the maps to half the size.
Another example is if your character is always aligned to an 8x8 grid, then the X,Y coordinates can be written to a single byte rather than a separate byte for each variable since there are only 12 X possibilities and 8 Y possibilities. Keep in mind though, that you should only do this if memory is a problem. Accessing bytes, and sometimes words, is actually fastest and smallest in the program when it comes to reading memory even though the actual data is bigger.
768
« on: October 08, 2010, 11:00:24 pm »
A one or zero is a bit. 4 bits = 1 nibble 8 bits = 1 byte 16 bits = 1 word Get it!? Half of a bite!  It's hilarious how so many terms in computer and electrical engineering are either about food or sex. It just shows what goes on in the mind of a programmer... You can hold 2 nibbles in 1 byte so they're mostly used for compression if you don't need 256 possible values and can use just 16 then you're using half the memory.
769
« on: October 08, 2010, 07:23:01 pm »
The game looks really nice!  By the way, the solution to your key problem is to add a "While getkey(0):End" after the key press is handled. This would cause the game to wait until all keys are let go before continuing. If you need background animations and other stuff like that instead of just waiting, you can call your animation subroutines from inside the while loop.
770
« on: October 08, 2010, 02:28:05 am »
But then the shades of the colors would still be in order i.e. the lightest color is the lightest and the darkest color is the darkest instead of a middle color. Also, it would be easier to convert since I think this is how its actually implemented in Pt-Mask().
771
« on: October 08, 2010, 12:11:57 am »
Why not just have white be transparent? Then light gray would be white, dark gray would be gray, and black would be black.
772
« on: October 07, 2010, 11:59:17 pm »
EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers. Same thing with the circle command.
I'd be ok with a whole second copy of the Line() routine being needed for the back buffer, or a more inefficient one for arbitrary buffers. I'm not terribly worried about speed, it would just be nice to have these for UI drawing.
Usually for a UI you only need strait lines in which you should use rectangles with singular width or height. Those can be drawn to the backbuffer. The menu context is interesting, I hadn't seen that before (since its undocumented) but I will certainly check it out. From the looks of it though, it seems really large and complicated if its implemented similar to the way BASIC does it. I don't know how I'd be able to take any amount of arguments either.
773
« on: October 07, 2010, 11:29:42 pm »
The Ans variable should be accessible already with "Ans"->Str1 just like you read other OS variables.
bcalls aren't useful to implement becasue of the reasons you're discussing now. bcalls require very specific register input and very specific register output. There wouldn't be an easy way to translate that directly to Axe syntax.
InsertMem, DelMem, and EnoughMem are possible, I will look into some good tokens for them.
There is no bcall for making menus as far as I am aware.
EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers. Same thing with the circle command.
I may support 8xY sprites, but I'm not sure yet.
774
« on: October 07, 2010, 01:12:00 am »
Yeah, I've already added that
775
« on: October 07, 2010, 01:02:19 am »
calc84maniac, I was thinking about that, and it's a great idea!
I also thought of an interesting new block type which is basically an anti-subroutine. Instead of calling a routine and then returning from where you called it, you tell it the place you want to return to and then do the routine. I'm wondering if that would be useful because I do that a lot in the actual parser code. In Axe and assembly, it's basically this:
SetRet(LBL)
...
Return
...
Lbl LBL
ld de,LBL
push de
...
ret
...
LBL:
The switch statement itself would use something similar. And since the return point is set to the end of the switch statement, I wouldn't need to add a new break command, you could just use "Return". The main problem though is that this would actually create memory leaks if you tried to do a goto out of the switch statement from within the switch statement. I think a common use of switch statements is branching to a bunch of labels though so I'd have to figure out another way to do that...
776
« on: October 06, 2010, 07:44:39 pm »
Infrared is only "Heat" becasue our environment is about 300 Kelvin and at this temperature we release the most amount of blackbody radiation at this wavelength. You are emitting as much radiation as you are absorbing because everything around you is about the same temperature. If you heat something up hot enough, say to 2000K, it starts to emit much of its radiation in the form of visible light which is why a glowing iron rod appears red after being heated. And if you go into space, you have a temperature of about 2.7K which is due to the cosmic microwave background radiation.
So the actual wavelength is only dependent on temperature. Its only infrared at room temperature.
777
« on: October 06, 2010, 04:51:57 pm »
The labels are just names, they don't actually exist in the executable so there would be no way to tell where you actually need to jump. ASM jumps function differently than BASIC gotos becasue the ASM uses the actual address in memory which varies wildly as your code grows and changes. I'm still trying to see if switch statements will be possible and save memory by the way, but I would need to add a break command or something which would be a lot of work.
The reason I don't have 8xY sprite drawing is because it will either make the existing routine larger and slightly slower or i would have to add a whole other sprite routine. It gets complicated due to the clipping.
778
« on: October 06, 2010, 04:40:19 pm »
They were disabled is for 2 reasons.
First of all, I wasn't sure if they still worked or not after mixing subroutines and data because I didn't do any testing with them after making this change. But it sounds like they probably do work so I guess it's just lucky that it still functions without having debugged. There might be other problems still with subroutines, token names, compatibility options, or at least some combination probably still doesn't work.
The other issue is that I am completely changing the axiom capability with "acalls". The acalls are similar to bcalls except they call axe routines instead of OS routines. They're basically just jumps whose label gets automatically replaced by the parser with the label of the axe routine in the program, inserting the routine into the program if it doesn't already exist. Works with all conditionals of jumps and calls too. Another new feature is adding options for the r modifier or double rr modifier to be used with axioms. There is also a new form for implicit storing where you can store to the function itself like how ->nib{} would work for example. With all these changes, the code was completely under construction so rather than commenting it out and replacing it with the old code, I decided to just keep it there but have it disabled until I actually finish it.
779
« on: October 05, 2010, 09:30:56 pm »
I'll definitely check out that bcall.
@Runer
If the sprite is 16x16 (and aligned to an 8x8 grid no clipping), you can actually write your own sprite routine in Axe itself that would be more efficient than drawing 4 8x8 sprites by copying the sprite data to the L6 buffer directly. I'm pretty sure I've seen someone do that before but I can't recall the thread... For 8x8 sprite drawing routines though, the speed would not be that significantly increased since the sprites are automatically not shifted when aligned to the grid anyway and clipping is a relitively small portion of the actual time it takes to draw a sprite. Aligned sprites draw fastest with Pt-Off() whereas unaligned sprites draw fastest with Pt-On() and Pt-Change().
780
« on: October 05, 2010, 09:20:09 pm »
Its not a bug, I just ran out of time and forgot to add it. I *should* have it next version.
Pages: 1 ... 50 51 [52] 53 54 ... 135
|
Show Posts