wczesniej nie wyroznialem tego pojecia ale
teraz przyszlo mi do glowy by to wyroznic
bo to oddaje pewne subtelnosci

scena (w grze czy symulacji) ma pewien stan
ale jest on opisany dosc abstrakcyjnie (aczkolwiek
scisle i jednoznacznie)

jesli ktos chce wyrenderowac scene to musi zbudowac
'draw_state' (ktory w sumie tez jest jednoznaczny ale
jest odzielnym stanem)/ zbudowac draw_state czyli przetworzyc
scene_state na draw_state

nie sa dla mnie jasna np dwie rzeczy:

1. czym dokladnie sa te draw state
1. co oddaje sie slowem 'render scene'

ad1 np w przypadku gier 2d osobiscie draw_state to
tworzona przeze mnie zawartosc rambufora/ prostokatnego
pixelbufora - ktory na koniec blituje do okienka

w przypadku gier 3d jednak za draw state mozna by uznac
w sumie trojwymiarowa geometrie zlozoną z listy tysiecy
trojkatow - dopiero pozniej sie ją przezyla przez
karte ktora ryzuje to na ekran

chodzi mi mw o to ze draw_state jako plastyczny opis
sceny jest drugim dobrze okreslonym duzym stanem w grze
ale ew nie koniecznie musi byc chyba dokladnie finalna
bitmapa na ekranie

(chyba ze cos tu mieszam)

ad 2 - co okreslic wtedy slowem 'render' ? bo o ile tak
to proces rysowania ma dwie czesci: 1 wygenerowanie render state
na podst scene state 2 wyrenderowanie okna przy pomocy draw state




















--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

to jest ciekawe tez o tyle ze pokazuje
ze dane sceny (potrzebne do calej mechaniki)
i dane graficzne (potrzebne tylko do prezentacji)
to nieco inne rzeczy, czasem zmieszane

najfajniej by bylo chyba operowac na samych
danych sceny (jak na virtualnych impulsach)
dane graficzne spychajac tylko do warstwy
prezentacji, to by odchudzilo sam kod sceny
- acz kto to wie (poki co nie patrzylem pod tym katem)


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

>
> ad 2 - co okreslic wtedy slowem 'render' ? bo o ile tak
> to proces rysowania ma dwie czesci: 1 wygenerowanie render state
> na podst scene state 2 wyrenderowanie okna przy pomocy draw state
>

wychodziloby ze sa dwa mechanizmy

scene_st --draw--> draw_st
draw_st --render--> window_st

(zaczalem sie nad tym zastanawiac wczesniej
myslac o podziale modulowym)

tak wogole to oprocz scene state i draw state
mozna dorzucic input_state (czyli np tablice
klawiszy klawki z ich stanami itp)



module main;

import windows,
input, blitter, hud,
dogs, bulls, crockodiles,;


void main()
{

// setup

windows setup_window("zoo game", 480, 320); // windows -
// prosty modul
// do uż okienek

for(;;)
{

// input state

input read(); //read input state (do tablicy
// w module input)
// scene state

dogs move();
bulls move();
crockodiles move();

// draw state

doggs draw(); // draw do pixelbufora w module bliter
bulls draw();
crockodiles draw();

hud draw();

// window state

blitter render(); //blit pixelbufor do okienka
}

}



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

<f...@N...gazeta.pl> napisał(a):

> >
> > ad 2 - co okreslic wtedy slowem 'render' ? bo o ile tak
> > to proces rysowania ma dwie czesci: 1 wygenerowanie render state
> > na podst scene state 2 wyrenderowanie okna przy pomocy draw state
> >
>
> wychodziloby ze sa dwa mechanizmy
>
> scene_st --draw--> draw_st
> draw_st --render--> window_st
>
> (zaczalem sie nad tym zastanawiac wczesniej
> myslac o podziale modulowym)
>
> tak wogole to oprocz scene state i draw state
> mozna dorzucic input_state (czyli np tablice
> klawiszy klawki z ich stanami itp)
>
>
>
> module main;
>
> import windows,
> input, blitter, hud,
> dogs, bulls, crockodiles,;
>
>
> void main()
> {
>
> // setup
>
> windows setup_window("zoo game", 480, 320); // windows -
> // prosty modul
> // do uż okienek
>
> for(;;)
> {
>
> // input state
>
> input read(); //read input state (do tablicy
> // w module input)
> // scene state
>
> dogs move();
> bulls move();
> crockodiles move();
>
> // draw state
>
> doggs draw(); // draw do pixelbufora w module bliter
> bulls draw();
> crockodiles draw();
>
> hud draw();
>
> // window state
>
> blitter render(); //blit pixelbufor do okienka
> }
>
> }
>
>
>
jest to maly szok ale jest to tez ciekawe,

ciagle mam za to problem z modulami do instancjonowania
(pisalem o tym juz kiedys w watku pt tablice modułów)
(mozna tez nazwac dla uproszczenia 'modulami abstrakcyjnymi')

problem objawia sie wieloma aspektami na raz, poki co
wymyslilem ew by przemyslec muduly z funkcami
oprogramowywujacymi nie instancje tylko definicje

cos w stylu

module Bird;
imports map;

struct Bird { float x,y,a,v,h,dirx,diry; };


void init()
[
}

void rotate()
{
}

enum observe(float x, float y, float radius)
{
mab return_agents_at_place(x,y,radius);
}

void move()
{
float nx+=Bird.v*Bird.dirx;
float ny+=Bird.v*Bird.diry;

if(bird observe_place(nx,ny, 10) == 'nothing')
map move_bird(nx,ny);
}

act()
{
move();
}




module birdss;
imports Bird;

Bird bird[100];

move()
{
for(int i=0; i<lenght of(bird); i++)
{
if(bird[i].enabled
bird[i] move();
}

}


ale jest tu pare drobiazgow w kwestii -

(tymczasem bardzo wyraznie widze w jakiej dennej
formie fizycznej jestem (niby kosci po kleszczu
bola w czesci mniej ale moja forma fiz i tak
jest ekstremalnie beznadziejna, i nie mam pomyslu
jak sie podciagnac )




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry