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 - ben_g
Pages: 1 ... 13 14 [15] 16 17 ... 71
211
« on: January 14, 2014, 05:01:28 pm »
I've downloaded the GCORE version of the tutorial post (edit: it says "Version 2.0 omega" in the program editor), and when I try to use it, it thrown an undefined error at GGenBuffer and GUpdateBuffer.
I've checked them for typing mistakes, but they looked correct.
What am I doing wrong?
EDIT2: I've looked at the source code, and it looks like it should be GGenVBO and GUpdateVBO instead of GGenBuffer and GUpdateBuffer. It works with those.
212
« on: January 14, 2014, 08:36:06 am »
I find it quite ironic that they use an apple to cut an apple
213
« on: January 13, 2014, 02:23:47 pm »
I don't know if porting older b&w games would be feasable. For some it's deffinately possible, but it's not a good idea for all games.
The games for the b&w calcs are designed to look good in b&w, and many of them have graphics that would be slow or hard to do on the color calc because of having not enough RAM for a graphics buffer (especially not multiple). For this reason, don't expect to see many smoothscrolling games, or games with mode 7 or raycasting.
Fortunately, the higher resolution and color of the new calc do also have some good parts. You can fit a lot more on the screen, and everything will look much better. It also has more flash memory than other calcs of the same line. So, while many 84+ games are about action and moving levels, many CSE games will probably have static levels where only a few things move. This could lead to some great puzzle games, and maybe also some point&click games. And RPG's are very possible as well, but instead of having smoothscrolling, they will probably be more like the ASCII RPG's on the 84+, but with much better graphics.
Moral of this post: It's probably much better to think of new game concepts that go hand in hand with the new high-resolution color screen then to try to port the old b&w games.
214
« on: January 10, 2014, 12:50:47 pm »
If you don't solder the wires to the calc, then make sure they're attached firmely to the calc, because if one gets loose, then you'll get a RAM clear (like if you pull a battery)
215
« on: January 10, 2014, 11:31:14 am »
that's a good idea, i might consider that. thanks 
but my question still isn't answered.
are there any adaptors for the 84+SE or could i construct anything myself?
Find an adapter that has an output of 5-6V DC (you may be able to use an old cellphone charger for this), cut the plug that goes in the cellphone/watever device it was meant for, strip the ends off the cable and solder the + wire of the adapter to the + side of the battery compartiment (the batteries are all connected serially, connect it to the only + side that isn't connected to the - side of an other battery), and solder the other wire to the - side of the battery compartiment (which is the - side that isn't connected to any + side). You probably also want to cut the cable somewere between the calc and the plug and solder a connector inbetween. The most important parts are: - Make sure the output of the adapter is not higher than 6V - Make sure the output of the adapter is DC, not AC - Make sure the polarity is correct. Use a voltmeter to test this. If you respect the above, your calc should be fine, regardless of what happens. But to be really sure, wait for someone who knows more about how the calc functions to verify this post.
216
« on: January 07, 2014, 02:54:43 pm »
It sounds like an interesting project, but I don't fully understand the purpose of this currency. How would you earn some of this currency? And on what can you spend it?
217
« on: January 07, 2014, 12:22:28 pm »
so, GUpdateBuffer(id) transforms all the vertices? That seems like a quite simple syntax, but when the amount of vertices changes, do we have to generate a new buffer every time? Because that sounds kinda slow
218
« on: January 06, 2014, 01:05:19 pm »
Z-ordering is indeed not perfect, and (while the problem seen in that image is very uncommon) it won't be able to draw intersecting polygons correctly. If you want to draw it correctly, you'd need Z-buffering, which needs a lot of RAM. And unfortunately, the 83+/84+ hasn't got much ram. EDIT: 
219
« on: January 06, 2014, 09:55:56 am »
Feature request: could you add billboards? (basically sprites that always face the camera)
Because they always face the camera, only their scale changes based on the distance, not their persfective. Because of this, they only need 1 point to be transformed to get the on-screen coordinate of the sprite, and then you just draw a scaled sprite at that location. For the Z-ordering and finding the location and scale, you can probably re-use some code of the sphere drawing routine.
220
« on: January 05, 2014, 10:33:01 am »
Yea, not everyone would need lighting for his project, so I guess a shader for it is indeed the best option.
BTW, have you made any progress on backface culling and z-ordering?
221
« on: January 05, 2014, 08:18:00 am »
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?
well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult 
would it be slow/hard to recalculate the light direction based of a certain point for every vertex or for every 4*4 pixel area?
I am not sure for what you mean, but if you think of a sort of per-vertex lightning ; a modification of the texture routine allow me to do some sort of gouraud shading.
Yes, that's what I meant. And for the pixel area, I meant some kind of per-pixel lightning, but since that would be too slow, it could be done for every 4*4 area of pixels. But vertex lightning would probably be faster, and the higher accuracy of per-pixel-lightning is probably useless because of the dithering and the small amount of shades (compared to a good screen) anyway.
222
« on: January 02, 2014, 12:08:08 pm »
gelukkig nieuw jaar! 
(a little bit late but whatever )
Since Dutch is already taken, I'll say it in my other language: public class NewYear{
public static void main(String[] args){
System.out.println("Happy new year!");
}
}
223
« on: January 02, 2014, 11:36:44 am »
That looks really good. It seems like a great effect to make a dark environement.
Would it be hard to do lights at a different position as the camera, and multiple lights?
well, with the way I calculate the illumination, only directionnal light can be defined ; but mutiple and different light are not so difficult
would it be slow/hard to recalculate the light direction based of a certain point for every vertex or for every 4*4 pixel area?
224
« on: January 02, 2014, 11:28:18 am »
combinaison of both dithering and texturing. Note that this is at 15MHz. 6MHz is not *that* slow, but the screen is faster and look better like this 
and thanks Xeda !
That looks really good. It seems like a great effect to make a dark environement. Would it be hard to do lights at a different position as the camera, and multiple lights?
225
« on: December 31, 2013, 07:02:38 am »
The solid tunnel looks really cool, but when you get over 1000, it looks like the segments of the tunnel aren't all at the same distance from eachother. Is this intentional, a bug, or just an optical illusion?
Pages: 1 ... 13 14 [15] 16 17 ... 71
|
Show Posts