|
Post by Supermonkey on May 13, 2010 16:23:16 GMT -5
I think I've said this in a couple of posts before, basic4gl doesn't need a revamp it needs some substance to it. I don't have time for basic4gl, I won't have time for basic4gl any time soon. I'm frying bigger fish so to speak I have to pay bills and b4gl doesn't do that...
|
|
|
Post by Darkjester on May 13, 2010 16:40:43 GMT -5
I love how everything on this forum is pure oppinion
|
|
|
Post by Supermonkey on May 14, 2010 5:12:29 GMT -5
What else would it be? I'd like to see someone try and prove, using factual evidence that basic4gl needs major modification in order for it to be a success. DJLinux hit the nail on the head, why try to make b4gl better when you don't use half the features as it is? That's as close to a fact as you'll get, I mean check the demo programs board, it's not exactly full of high quality demos.
|
|
|
Post by shadow008 on May 14, 2010 7:09:41 GMT -5
Agreed, though i would like to see some improvement with Basic4gl , some programs i make end up being limited to what basic4gl can currently do. What the hell have you been doing?! Ive only hit b4gl's limit when using over 1k individual sprites at the same time. Other than that, I've been able to render 56k poly's at 140 fps.
|
|
|
Post by Darkjester on May 14, 2010 12:27:59 GMT -5
What else would it be? I'd like to see someone try and prove, using factual evidence that basic4gl needs major modification in order for it to be a success. DJLinux hit the nail on the head, why try to make b4gl better when you don't use half the features as it is? That's as close to a fact as you'll get, I mean check the demo programs board, it's not exactly full of high quality demos. ill agree with both side on this, i never meant a major modification i just mean an update, i was referring to more of a bugfix release i have seen some pretty bad bugs, even at the hands of some of the best writtin programs i have seen, as for the poly limit with some algorithms you can increase that exponentialy, raw poly limit i have found is more dependent on how you code it, with a display list i have found you dont get real lag till you hit roughtly half a million tri's
|
|
|
Post by crazynate on May 14, 2010 16:21:16 GMT -5
Agreed, though i would like to see some improvement with Basic4gl , some programs i make end up being limited to what basic4gl can currently do. What the hell have you been doing?! Nothing much, but I hate that sprite dimensions HAVE to be powers of two or: A. they can't be loaded B. they are really distorted when they are displayed Limiting might not be the best description, but Basic4gl's sprite loading/handling is frustrating at times, mostly when i want a sprite to be a certain size without it being distorted (gui,images with text, etc).
|
|
|
Post by Supermonkey on May 14, 2010 17:50:12 GMT -5
I can see how making b4gl open source, and chopping and changing bits that people agree aren't great, without having to get too heavy into the compiler code could be beneficial. Making big changes just won't be managed correctly imo. I thought we had this discussed in the other thread? i.e. getting b4gl on sourceforge and with a change of licence before trying to change the language?
|
|
|
Post by Nicky Peter Hollyoake on May 16, 2010 8:16:33 GMT -5
I think b4gl is doing fine how it is I mean I haven't stopped using it anyways.
Lets forget new versions, forget crazy idea's, and work at ya own pace and show new incomers that its not a failed language.
- Nicky
|
|
|
Post by aphoticgenesis on May 16, 2010 8:40:04 GMT -5
I think b4gl is doing fine how it is I mean I haven't stopped using it anyways. Lets forget new versions, forget crazy idea's, and work at ya own pace and show new incomers that its not a failed language. - Nicky WIN
|
|
|
Post by shadow008 on May 18, 2010 11:30:55 GMT -5
ill agree with both side on this, i never meant a major modification i just mean an update, i was referring to more of a bugfix release i have seen some pretty bad bugs, even at the hands of some of the best writtin programs i have seen, as for the poly limit with some algorithms you can increase that exponentialy, raw poly limit i have found is more dependent on how you code it, with a display list i have found you dont get real lag till you hit roughtly half a million tri's yeah.... twasik4.ucoz.com/_ph/1/2/407047763.jpgi dont think so.... btw: dual core intel processors 2.5 gigs ram shitty intel graphics card... -schools comps EDIT: to what triston said below; NO IT DOES NOT!!!!!!
|
|
|
Post by twasik4 on May 18, 2010 11:32:46 GMT -5
sooo.. cole.. does this mean i have another 110,000 poly's? xD
|
|
|
Post by Darkjester on May 18, 2010 14:47:02 GMT -5
dual core intel processors 2.5 gigs ram shitty intel graphics card... hmmm maybe check your looping? or load everything into a display list before you put it into your main loop? trust me you should be able to get at least a thousand tris in software on that config dunno bout texures or multitexture though
|
|
|
Post by shadow008 on May 18, 2010 18:29:00 GMT -5
dual core intel processors 2.5 gigs ram shitty intel graphics card... hmmm maybe check your looping? or load everything into a display list before you put it into your main loop? trust me you should be able to get at least a thousand tris in software on that config dunno bout texures or multitexture though I did. It swaps buffers before doing other calculations, its in a display list, but it also has tokamak physics running with it, sooo..... maybe its the physics. There's also the fact that terrain wouldn't be like that, it would have different facing polys, and cull face would reduce the drawing by about half - which actually works in increasing frame rate (someone said it didn't do anything (i think nicky)).
|
|
|
Post by aphoticgenesis on May 18, 2010 18:57:58 GMT -5
dual core intel processors 2.5 gigs ram shitty intel graphics card... hmmm maybe check your looping? or load everything into a display list before you put it into your main loop? trust me you should be able to get at least a thousand tris in software on that config dunno bout texures or multitexture though I did. It swaps buffers before doing other calculations, its in a display list, but it also has tokamak physics running with it, sooo..... maybe its the physics. There's also the fact that terrain wouldn't be like that, it would have different facing polys, and cull face would reduce the drawing by about half - which actually works in increasing frame rate (someone said it didn't do anything (i think nicky)). for terrain i would reccomend using VBO's or Vertex Arrays, i think DjLinux recently made a plugin for it. GOOD LUCK
|
|
|
Post by DJLinux on May 18, 2010 19:19:21 GMT -5
Let it be you can't compare OpenGL CPU software rendering with GPU hardware rendering.
Joshy
|
|