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 ... 13 14 [15] 16 17 ... 135
211
« on: October 10, 2011, 01:34:13 am »
You might want to note that there actually is a difference between 8.8 fixed point and inflation: 8.8 is signed while inflation is unsigned. The fixed point multiplication and inverse routines won't work as expected for larger values if you're treating them as unsigned. Another effect of that is that 8.8 numbers should be deflated with //256 instead of /256.
Your tutorial is about inflated numbers though, and it does a good job in that respect, you just don't want to make people think that those 2 methods are identical because the operations you do with them are slightly different.
212
« on: October 09, 2011, 10:42:11 pm »
MIDI to Axe Converter 2.0This new version features a graphical interface so its easier than ever to use. The coolest new feature is probably the "Preview" feature which runs my own little sound simulator to simulate how the end result will sound before you do a conversion. It also has some new controls to adjust the pitch and frequency cutoff (which is the lowest midi note to be included in a conversion). There is now an option to export with the player as well. Another thing, I have compiled the binary for windows, but I also included the source code so you can use Qt to compile it for other operating systems. Enjoy! Some samples are included for your listening pleasure 
213
« on: October 09, 2011, 08:45:52 pm »
Instead of scanning the pixels in the back buffer and projecting them to the front buffer, you will get better results if you scan the front buffer and inverse-project from the back buffer. This assures that every pixel is accounted for which won't happen if you do it the other way.
But as far as speed I don't think you can optimize more than that. As Qwerty said, definitely pre-compute the sine and cosine before your for loops.
214
« on: October 09, 2011, 07:17:27 pm »
The 'Soragora' logo overflowed beyond the sides of the screen slightly on startup and is placed slightly higher then the center of the screen (not sure if those were intentional) Yeah, that was intentional. We're going to change it eventually though. Where its displaying the welcome messages, 'feedback' is misspelled.
HA! I can't believe I missed that! It could have just been my location (or settings on my phone), but it was taking a long time to find my location + I'm in my house right now, so I can't really comment on the actual app itself (just nitpick  ). I'll re-edit this post (or make a new one) once I actually get a chance to really use this. If you're indoors, it will take a VERY long time to get a GPS signal if you even get one at all. GPS only works outside. Glad you all like it
215
« on: October 08, 2011, 07:25:01 pm »
Hey guys, some of you might know I'm working with a startup doing augmented reality! Basically what it is, is a new way to discover new places around you. You simply point your smart-phone at any building and overlayed on the camera is a descriptive icon. You can find useful information about each place such as ratings, reviews, menus, contact info, photos, check-ins, and much more. So if you live in the US and have an Android phone, check us out! We are planning to eventually expand globally and for iPhone too. Here's a video demo and a link to our app on the market place: SoragoraLet me know what you guys think. Try it out if you can, but if not, it would still be useful to know how you would use something like this. What kind of content would you like to see? Any negative feedback (we really need some)? Also, like us on facebookThanks 
216
« on: October 08, 2011, 07:39:28 am »
Line clipping actually IS very difficult. there are 2 ways to do it, either pre-clip and then use the routine normally, or clip every individual pixel that would be on the "virtual" line so all that's left is on the screen. That second option is what I used to do when lines were clipped in the past, but this was more than twice as slow and could only work with one buffer (like the circle command currently, and for the same reason).
To take the first option and actually compute new boundaries for the line involves a lot of extra math, needing several calls to the multiplication and/or division routines. The speed at this point would most likely be at least as slow as doing the pixels individually and way WAY bigger. I want the line clipping very badly as well but its not exactly an easy fix to make unless it becomes an extremely specialized command.
217
« on: October 07, 2011, 03:04:10 am »
@Runer: That makes the syntax deceptively misleading. If I allow Constr then a user would assume that Varr would work that way as well. Since Varr is valid syntax it is definitely misleading.
218
« on: October 06, 2011, 09:25:08 pm »
If compiled for Ion it cannot be ran from Asm() Actually it can, and it's always been able to
219
« on: October 06, 2011, 06:30:20 pm »
Thanks IMPORTANT SYNTAX CHANGEI am planning to make a non-minor syntax change in the next version. If anyone is opposed to the following, please let me know now. This will likely cause incompatibility with a few programs, but its a very easy correction to make to your program. The change involves the Data() command with 2-byte values. The current syntax is Data(C1,C2 r,C3) to indicate that C1 and C3 are taken to be single byte values whereas C2 is taken to be a 2 byte value. This works okay for now because C1 and C2 are constants or constant expressions but this syntax does not work with other expressions because you could have an expression that ends with an R, like for instance nib{} r and it would be impossible to tell if you meant nib{} as a 2 byte number, or nib{}r as a 1 byte number. Now given that, the Data command still only takes constants, but I am adding a new command for sequential data writing that CAN take expressions, and I would like the 2 commands to be consistent. My current idea is that any expression fully enclosed in extra parenthesis will be taken as a 2 byte number and otherwise a 1 byte number. In the case of Data, this would look like: Data(C1,(C2),C3) I personally think this is more readable anyway and easier to type since you don't have to go through any menus. Any thoughts or other suggestions?
220
« on: October 05, 2011, 04:25:23 pm »
32 bit numbers and floating point are not planned. The z80 processor operates in 8 and 16 bit modes and any 32 bit operations have to be done in software. There is also no hardware support for floating points, so this is even more expensive to do in software. If you don't mind the slowdown and complexity though, there are routines you can write in pure Axe to treat 2 or more variables as single larger variables.
The alternative to floating point is fixed point notation, which is supported in Axe. This allows numbers from about -128.00 to 128.00 with a precision of about .004. I'd say about 90% of games can avoid using fixed point or big numbers all together, but with the recent increase of physics platformers, maybe that statistic is lower.
221
« on: October 05, 2011, 04:09:14 pm »
Apparently the delay I added is not enough, there is currently 19 T-states between the port commands not including the port commands themselves. I think 7 are required for 6MHz so I assumed that 7*(15/6) = 17.5 I am still over the minimum. But maybe it was 8 T-States? Then I would need at least 20, putting me under. I can add 3 T-States and keep the routine the same size, so I'll probably just do that. No slow downs in games would be noticeable as a result of this, but hopefully it should solve this problem for good.
222
« on: October 05, 2011, 03:56:28 pm »
Velocity is volume I think. How about midi instrument as another argument, THAT would be as good as it gets But seriously that's better suited for an Axiom. Hardly anyone uses sound anyway since its so processor intensive, basic blips are about all you can use for most games anyway just because of speed issues.
223
« on: October 05, 2011, 05:26:21 am »
Yeah, I was thinking of changing the Bitmap() command's code to use a custom, fully clipped routine that would make it more useful. Currently its used very rarely because the OS's routine is slow, buggy, and just sucks. I don't mind having a big bulky routine as long as the ease of use makes up the difference. If either you or Runer or anyone else wants to design a routine, I'd be happy to include it. It needs: - Clipping in all directions
- Supports aligned and unaligned sprites
- Sprite dimensions built into data
- Data itself can be in any format (byte aligned not necessary)
- Usable on any buffer
- Extra argument to allow both "Or" or "Xor" drawing methods ("And" would be nice too)
Don't worry about the register/stack juggling for input, I can optimize that myself. The complexity of this routine is the only thing holding me back right now The reason for the last condition is that I don't want separate routines for each method, this is a command that should be optimized for usefulness, not for size or speed. If you needed the later, you'd be using 8x8 or smaller anyway.
224
« on: October 04, 2011, 06:57:27 pm »
Here at Berkeley, they actual combine EE and CS into a single major: EECS and I have to take classes in both. I can clarify what the difference is between computer engineering and computer science is:
Computer science studies: algorithms, artificial intelligence, compilers and interpreters, computer vision, optimization, and other fields like this. Its mostly the actual science behind all the programming.
Computer engineering is more about: Code organization and style, creating large scale projects, computer systems, documentation, abstraction, version control, etc. Its the engineering to create code, how to actually build real world projects.
Electrical engineering does have some fields that are mostly CS too: instruction set architecture, signal processing, and robotics to name a few.
But for any one field, they aren't ever insanely focused on one subset of CS. Generally, any CS department regardless of how they label themselves will offer classes in all of these things. So it doesn't really matter what the program is labeled as, just find a good one you like. Also, game design is something too specific to major in, I don't think most colleges would have a department just for that. It's more like what you want to do after college. Most do have a game makers club or similar, so you can always join that. You can search by rankings as a start, but it really comes down to how their program sounds to you. Maybe talk to a student there and ask whats good and bad.
225
« on: October 04, 2011, 05:36:39 am »
{CONST} or {CONST + Var} produces a 'Wrong # of Args' error 
Thanks, I just caught that. A workaround for now is to just add the constant after the variable: Var + CONST, which is more optimized anyway.
Pages: 1 ... 13 14 [15] 16 17 ... 135
|
Show Posts