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 - Builderboy
Pages: 1 ... 8 9 [10] 11 12 ... 375
136
« on: November 14, 2012, 09:51:54 pm »
Here it is, taken directly from FireFall.
137
« on: November 14, 2012, 09:33:41 pm »
Thanks shmibs, but I actually remembered I had one from Firefall that also did lowercase and numbers, so I'm gonna grab that one. Also, as a small update, I finished the build program to generate the Portal data-appvar, and modified Portal itself so that it reads from the appvar instead of internal data. Moving the data out of the app freed up around 3000 bytes, so I'm super excited! One more thing to check off the list!
EDIT: I actually went ahead and modified the list I made earlier with an update as well
138
« on: November 14, 2012, 12:15:09 am »
Alright, I decided it would be nice to post a little list of all the things that have to be completed before the game is released, as well as how far allong each of these tasks are from being completed.
1) Transfer all built-in levels and speech text into an external appvar. The main hurdle here is making the program to build the appvar, since it needs to be modular to allow changes to the text and whatnot, but still allow all the pointers to work such that the Portal App can access everything. Originally I was going to hardcode all of the levels into this builder, but then I realized that was a bit silly, seeing as how I already have a level editor that will do everything I need in terms of ordering levels and making sure pointers are correct. So the builder merely assimilates an appvar produced by the level editor, and adds in a seperate pointer table for all of the text strings. The builder is all finished now, all that needs to be done now is to build the actual levels to put in the pack.
2) Code the middle and ending min-cut-scenes. These are super small and pretty much are just a small amount of animation with some text. I already have the word wrapping routine written, so that is finished, and now I just need to code the animation. Once I have a proper appvar to work with, getting output text should be relatively simple as well. This includes the ending credits as well, I'm just considering that as a part of the ending cutscene. I'm still thinking if I shouldn't add some sort of reward once you beat the game like the super-portal-gun in the original.
3) Finalize the levels that are going to be in the game, as well as what order they are going to be in. Leafy is helping me out on the level creation front to bring in some new ideas, but most of the levels will remain the same from the closed-alpha a while back. However, since all the level data is going to be in an external appvar, I can have much more than just 30 levels, so that should be lots of fun! I also have a few more graphical effects I need to code, but that is just ascetics and shouldn't take long at all.
4) Allow creation and renaming of level packs for the editor. Currently the level editor can only edit level packs, and not create them, and this is mostly due to the fact that I have been putting off writing a text input routine. If anybody knows of a good text input routine that I could borrow, that would be great! All finished! The level editor is 100% workable!
That's it! Everything else is finished!
139
« on: November 13, 2012, 06:11:28 pm »
This looks like a fairly good calculator, but I am pretty worried as to how the new screen might limit games, instead of benefit them. The reason I am worried is because the screen has been scaled up by a factor of 100 (320x240 = 76800 pixels to write to, whereas the regular 84/83 only has 768 bytes of screen memory). This new screen is significantly larger than the 83/84, but the processor is at most 5 times faster, which means for programs that need to update large portions of the screen every frame (like tilemappers), there might be a large amount of slowdown.
140
« on: November 13, 2012, 04:42:02 pm »
Once I finish portal prelude I will definitely try to join this!
141
« on: November 13, 2012, 03:15:58 am »
It's also worthy to note that full compatibility with asm programs would likely be impossible without some sort of compatibility mode, due to the fact that the new display is so completely different than our current black and white one.
142
« on: November 09, 2012, 03:46:34 pm »
So it has been a while! I've actually resumed work on this recently in secret, but with all the talk of "Omnimaga saving" I thought this might be a good time to announce the progress and generate a little more interest! The majority of the recently progress has been in designing and completing the level editor, which is finally in a workable state! Me and leafy are working together to generate the final level-set, upgraded and improved since the closed alpha release several months back, while I am working to finish up the polish and other content to make this more than just a fun game engine with a built in levelpack. All in all, you can expect frequent updates, screenshot teasers, and a release date set before the year is over!
143
« on: November 09, 2012, 03:41:00 pm »
I know that DJ has for the most part been uploading tribute videos and such to his own youtube channel. But, if we really wanted a dedicated channel to our own, we could always create a new gmail account specifically for omnimaga videos, and then link it to a new official youtube channel.
Furthermore...
*Builderboy runs off to revive an old thread*
144
« on: November 09, 2012, 05:53:44 am »
Welcome to Omnimaga indeed  And I am a little confused by your notation. When you say Sum, do you mean integral?
145
« on: November 08, 2012, 11:39:41 pm »
That doesn't sounds like more precision at all! That sounds like a larger range with the same amount of precision 
146
« on: November 07, 2012, 06:00:47 pm »
You can use the Bitmap function, but I think it's even slower because the routine is written by Texas Instruments and is not as optimized.
Actually Axe got a new bitmap routine written for it that is much more functional and super fast I know if it is better than using 4 sprite calls, but it is nice and speedy if you have even larger moving images ^^
147
« on: November 06, 2012, 04:34:38 pm »
How about you put the board display routine in a subroutine? That way you can display it whenever you need to with minimal size increase.
148
« on: November 04, 2012, 02:30:57 pm »
in the meantime you can simply keep all your data external and try to work around a 16 KB limit for code This is very hard to do with text data. You must calculate how much bytes you have in your text (knowing that uppercases take 1 byte and lowercases take 2 bytes) and you can't easily access the nth string without copying all the data to RAM 
But for every other kind of data, it is very possible 
I just wanted to point out that if we are working with character data like Axe strings, uppercase and lowercase both take a single byte.
149
« on: November 02, 2012, 02:56:29 pm »
The behavior of that wall on the left makes me think that you're detecting collision with the block sides parallel to the screen instead of perpendicular (which should be closer).
It could also be that the ray stepping is too coarse
150
« on: November 01, 2012, 07:10:40 pm »
the "fishbowl effect" is natural. the issue is that a screen is just a much smaller width than the total width visible by a human, so the angle must be much smaller
The fishbowl effect is not natural for humans to perceive, and this is because we have a radial cornea instead of a flat one. The math behind raycasting uses a flat cornea, and thus the fishbowl effect is created, which does indeed making things look unnatural. In 3D graphics, straight lines should appear straight As for what is causing the weirdness, check to see if you are using radians or degrees, as it looks like the error is happening because of some mismatch. For the Field-of-View, i would recommend 60 degrees.
Pages: 1 ... 8 9 [10] 11 12 ... 375
|
Show Posts
