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 - Runer112
Pages: 1 ... 145 146 [147] 148 149 ... 153
2191
« on: June 12, 2010, 06:04:24 pm »
Well you won't need to display grayscale any more, so just do normal display. Then, you'll need to modify the logo drawing routine to include another bitwise operation to copy the sandstorm to the front buffer as well.
2192
« on: June 12, 2010, 05:54:29 pm »
So do you want me to give you code for it? Or should I let you do it and guide you if you need help?
2193
« on: June 12, 2010, 05:18:41 pm »
Wait... so you have it working?
EDIT: Nevermind, just realized that's a BASIC program. Should I give you code for it? Or should I let you figure it out with a little help if you need it?
2194
« on: June 12, 2010, 05:03:12 pm »
How do you want it to blacken the screen? Can you describe it?
2195
« on: June 12, 2010, 04:32:03 pm »
I modded my post to show what I did with that code. Thanks ztrumpet 
For(B,-64,64,1.9)
Line(-96,-B,96,B
End
For(B,-96,96,2)
Line(-B,-64,B,64
EndOk, so: - Setting the increment for For() loops is not a supported feature. You can only increment by one (for now at least)
- Decimals are not supported. All variables in assembly are 2-bit integers, so 0-65535 or -32768-32767.
- The dimensions of the screen are 96x64. This means that pixels have an x-value ranging from 0-95 and a y-value ranging from 0-63. There is no need for drawing the lines into negative pixels, or all the way to x=96 or y=64.
- And what exactly are you trying to achieve with this code? I can't quite tell.
2196
« on: June 12, 2010, 04:24:57 pm »
Setting the increment in for loops is not supported. Neither are decimals. And what exactly are you trying to do with that code?
2197
« on: June 12, 2010, 03:51:01 pm »
Good sir, I don't believe all of those commands in above program work.
See: It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot
2198
« on: June 12, 2010, 03:46:55 pm »
I heard something about a sandstorm? EDIT: Sorry about the double post, just realized 
2199
« on: June 12, 2010, 03:28:32 pm »
ah. Nice! Thanks man. but.. is there any way to get rid of the white line on there?
Oh, is that not part of your data? Your source program said to copy 312 bytes from Pic1 to the buffer, apparently you only needed 298.
2200
« on: June 12, 2010, 03:14:19 pm »
You lost a little speed, but I believe this is the outcome you were looking for. It would probably run a bit faster if you either: - Re-entered the logo data inverted so you didn't have to include "65535□" in the logo drawing subroutine
or - Before the main loop, copied the logo to the back buffer, inverted the back buffer, copied the inverted logo to another location such as L₁, and then referenced "{B*2+L₁}ʳ" instead of "65535□{B*2+Pic1}ʳ in the logo drawing subroutine"
2201
« on: June 12, 2010, 02:23:32 pm »
Like this?
EDIT: Wait hold on, fixing a bug.
EDIT 2: Attached.
2202
« on: June 12, 2010, 02:04:14 pm »
What do you mean by "is it the smallest syntax?"
EDIT: If you mean is that the most size-efficient way to produce a random integer in that range, yes.
2203
« on: June 12, 2010, 01:59:13 pm »
It might be nice if somebody made a converter (even if just a BASIC program) where you select the starting and ending range for your randomizing then converts it to Axe format, because I find rand kinda hard to work with, since it uses such high values. A converter (that produces the appropriate needed code) would help a lot
To produce a random integer between start and end: rand^( end- start+1)+ startFor example, 1 to 10: rand^(10-1+1)+1
rand^10+1333 to 666: rand^(666-333+1)+333
rand^334+333
2204
« on: June 11, 2010, 11:30:53 pm »
btw do you draw the entire "squares" on the screen every frame, or just erase the end and add a line at the beginning of them? If it's the former, you could simply increase the rate at which it moves. It would look faster, even if the framerate isn't too high.
Latter. As it is, with drawing only a single line for each square on each side (16 lines in total), I only get about 6 frames per second at best. Drawing every object over again every frame would undoubtedly be even more unplayable, I'd be lucky to get 2 frames per second.
2205
« on: June 11, 2010, 10:57:09 pm »
Yeah, the fastest I can push my program and still have it look decent is about 0.7 gridlines per second. Ideally I'd want at least 3 times that.  I wish I had a 15MHz calculator or ROM to test it on, it might at least be passable running at 15MHz. Otherwise I guess I'll have to scrap this and work on a non-3D project.
Pages: 1 ... 145 146 [147] 148 149 ... 153
|
Show Posts