Getting together for developing a Game?

[Wrath Of Khan]

One player might be the way to go Imo.

 

[Linux-SWAT]

I like the network play idea for a shoot'em up.

 

[Wrath Of Khan]

It's a nice idea, no offence but maybe we dont want to bite off more than we can chew.there may be alot of extra work in implementing multiplayer network play.

 

[ekianjo]

No need to keep adding features at this point - we have enough


We don't want to make a Homer Simpson's design car (a good image for feature creep) -

First the focus is to make a very solid single-player game.

 

[Wrath Of Khan]

I will start putting together some ideas in a document for game features/Level themes/look/weather conditions/music type/ and how the story fits into all of this tomorrow.The actual specific level designs and layout is another matter.Though I will consider enemy types in terms of the level type etc.A nemesis of some sort might be required too.Will think on it.@Ekianjo I will send you my ideas when I have something to show as you said you were able to commit to a game design document also.

 

[ekianjo]

.@Ekianjo I will send you my ideas when I have something to show as you said you were able to commit to a game design document also.

ALlright- I'll start working on the game design doc anyway, just send me your ideas when they are ready. Be very specific regarding how your ideas should work in practice, so that the coders don't have to "interpret" anything. It has to be crystal clear.

 

[Linux-SWAT]

I can help on the scenario.

 

[mjohansson]

Hmm I tried to compile my code myself, I had to change const GLchar* vv and const GLchar* ff to const char* vv and const char* ff in the CREATE SHADER section. After that it compiled.


However, the window consists of multicolored pixels, nonsensical garbage. But theres an interesting thing, when exiting the program it prints 1 for max texture size, wich is obviously wrong, and a very large seemingly random number for number of texture units, wich is obviously also wrong, that to me looks like the memory gets fucked up and wrong values goes into wrong spaces...

 

[mjohansson]

Hmmmmm I exchanged my old eglport for latest one, still same effect, but guess what, FPS went from around 55 with old to around 85 with new!

 

[mjohansson]

Its the shaders, they arent compiling...

 

[ekianjo]

Its the shaders, they arent compiling...

Any idea why ? Is that what is causing the memory leak ?

 

[mjohansson]

I cant use GLchar* on Pandora, it says expected initializer before '*'


I looked at compileShader on GLES2.0 reference page, it wants GLuint and I was using GLenum, I changed that but it didnt solve it. I think mayby its the lack of GLchar that is problematic? Using char instead otherwise it wont compile at all.

 

[ekianjo]

I cant use GLchar* on Pandora, it says expected initializer before '*'


I looked at compileShader on GLES2.0 reference page, it wants GLuint and I was using GLenum, I changed that but it didnt solve it. I think mayby its the lack of GLchar that is problematic? Using char instead otherwise it wont compile at all.

if you want to use char openGL requires GLchar. I'm not sure what is the issue with the initializer - maybe worth asking the other coders? (sample of your code would help as well)

 

[pmprog]

I'm trying to run my Sparrow3D testm but it keeps saying "libsparrow3d.so no such file or directory", but it's there in the same directory!? What am I doing wrong?


I made a PND, and works through that. Massive 9 FPS, however I was still trying 2 800x480 layers with 4 quads though.


What exactly are our requirements for parallax? ie, what type of background are we having? Obviously parallax can be achieved by just moving sprites at different speeds across the screen if we're only needing things like clouds & sun, or stars & planets etc.


Maybe we should focus on trying to get plenty of sprites onscreen and moving. After all, if we can't handle "the game", then there's no point worrying about the background...

 

[Ziz]

under Linux it doesn't search in the same directory as default like Windows.


It searches e.g. in /usr/lib or /lib.


To add your local folder to the search path call


export LD_LIBRARY_PATH=.


before your call or call it like the example-sh-files with


LD_LIBRARY_PATH=. ./your_application


(funny, was accident, that I read here, and the last post is a sparrow3d question ^^)


To your (edited - bad style! accident AGAIN, that I read it) stuff about fullscreen quads... What are you trying to do? It sounds wrong. For blitting surfaces or sprites (which are animated surfaces), I have faster function than QUADs...

 

[pmprog]

To your (edited - bad style! accident AGAIN, that I read it) stuff about fullscreen quads... What are you trying to do? It sounds wrong. For blitting surfaces or sprites (which are animated surfaces), I have faster function than QUADs...

We're doing parallax scrolling demos. Was just trying different methods to see what sort of framerates we could get. Would you recommend me try spBlitSurfacePart instead?

 

[Ziz]

If you don't zoom and rotate: Yes.


And if you sort it by yourself, don't forget to deactive zTest and zSet. Furthermore you don't have to reset the zBuffer. ;-)


Oh and if you draw on the whole screen tiles, you don't need spClearTarget neither.

 

[pmprog]

Oh and if you draw on the whole screen tiles, you don't need spClearTarget neither.

In my demo, I have two layers, but both with transparancy, so I do need to clear the target.


Using Sparrow I can get 50ish FPS with 2 semi-transparent (not alpha'd), but fullscreen parallax layers on the Pandora. Escape quits

par.zip

 

[Ziz]

Maybe the last (third?) layer should not use alpha, but have a one-colored background drawn on it (beside normal layer stuff like mountains or whatever should be on the last layer). In that case, you have a winwin-situation: One layer without ANY kind of alphatest (faster) aaand you don't have to clear the screen.


greetings,


Ziz

 

[ekianjo]

What exactly are our requirements for parallax? ie, what type of background are we having? Obviously parallax can be achieved by just moving sprites at different speeds across the screen if we're only needing things like clouds & sun, or stars & planets etc.

The point of background is to create depth of field - if you are on a planet, you could have a sea at the bottom, or ground with different levels of parallax, and different levels of clouds at the top. You could use sprite instead but that would limit you in the size of the background, I guess.


In space, you would have the obligatory small debrits/dust kind of background, and you could also get asteroid fields in the background with big asteroids as sprites in the foreground (for which there would be collision detection).

Maybe we should focus on trying to get plenty of sprites onscreen and moving. After all, if we can't handle "the game", then there's no point worrying about the background...

Plenty of sprites is "given". You would need tons of sprites on screen (probably a dozen or more for ennemies at once on screen), plus about 40-50 sprites for projectiles (of varying sizes). But we can't even figure a smooth background out, I don't think we can have a dozen of sprites on screen smoothly either.


Anyway, tackling the background is an "easy" problem (everyone is clear on what to achieve) and that will give us good leads on how to make an efficient drawing engine, and that knowledge can be reapplied to sprites after.