Ja mówię o GTA

--Cytat (denis333):
Po prostu tym wszystkim niewidomkom nie chce się robić graficznego interface, i wolą bazować na tekście, przekazywanym do czytnika ekranowego przez jakieś biblioteki ługi bugi na kiju.
--Koniec cytatu
Powiedział ten, któremu się cokolwiek po za powtarzaniem tego samego chciało. Mówiłem, zgrajcie się, nauczcie programować i wydajcie własną wersje Eltena. Jak Dawidowi i innym przypadnie do gustu, to może program się zmieni.
Ja sam nie umiem Rubiego, ale wiem ogólnie, że programowanie to nie jest pstryknięcie palcem, szczególnie gdy robi to 1 osoba.
Aby weszły kontrolki Elten musiałby zostać napisany od podstaw.
Sądzę, że Dawid nie jest chyba w stanie sam robić czegoś takiego, bo to za dużo pracy na jednego człowieka żeby teraz wszystko przeimportować.

CIekawe swoją droga jak sobie wyobrażacie standardowy tekst w grach Audio. Toż to by sensu nie miało żadnego.

Jakieś szybkie komunikaty przez to api śmieszne co przekazuje tekst do nvda, a reszta ogarniana normalnymi kontrolkami.

Na kontrolkach nie da się zbudować takiego interfejsu.
W najlepszym razie mielibyście forum z polami edycji pod tabem i zakładkami, bo 1000 pól edycji na WinAPI w życiu się nie zrobi.
Oznaczenie dźwiękowe nowych wątków chociażby? No cóż, brak.
Wstępne, ale zamiar mam rozbudować rozróżnianie dźwiękowe plików? Także brak.
Interfejs z dźwiękami na pola edycji, przyciski itp.? Także brak.

Elten w tedy został by pozbawiony tego dźwiękowego klimatu.

Musiałbyś tworzyć w takim razie dedykowany dodatek do Eltena tylko pod nvda i Orcę np

A dla mnie właśnie dźwięki są jedną z bardziej urzekających cech Eltena. Po prostu jestem dźwiękowym świrem i jak testowałam Eltena to nie myślałam, że to jest takie bogate

Moim zdaniem interfejs jest czymś, co buduje Eltena.
To on sprawia, że to jest Elten, a nie kolejny program, jak na przykład Pidgin na Linuxa.
Może to tylko moje odczucie, ale sobie w ogóle nie wyobrażam Eltena jako zwykłego programu win32.

Jako użytkownik już wolał bym brak dźwięków i stabilnie działającą aplikację niż to, co jest obecnie. Gdzie nawet nie da się niczego szybko usunąć bo się robią jaja. To samo jest w wielu obszarach. Po za tym, na niektórych sprzętach przekazywanie poleceń klawiszowych to jest jakiś dramat. Choć i tak jest lepiej niż kiedyś. Ale umówmy się: Coś co jest pośrednikiem nigdy nie będzie działało tak dobrze jak to, co bezpośrednio bierze tekst z kontrolek i jest od kilkunastu lat przystosowane pod czytniki ekranu.

Nie wiem, ale ja nie mam żadnych jaj

Denis kiedy TY ogarniesz, ze to Twoje niestabilne działanie jest wynikiem aktualnie używanego silnika?

Problem przekazywania tekstu z klawiatury nie jest związany z kontrolkami, nie bezpośrednio przynajmniej.
Ten problem jest rozwiązany od dawna, przynajmniej z programistycznego punktu widzenia.
Zgodnie ze standardami WinAPI i zaleceniami na samej stronie Microsoft for Developers.
Problemem jest RGSS, które się straszliwie przycina, gdy tylko coś raczy musnąć procesor bardziej.

Dlatego tak jak mówię: Mam nadzieję, że elten 3 będzie stabilny tak samo jak program ze standardowymi kontrolkami.

@pajper powiedz mi jedną rzecz. Czy ten owy silnik wreszcie umożliwi mi wzięcie większy udział w rozwoju projektu?
Bo ja tak patrzę, na to, że mam ten status programisty na Eltenie a i tak nic nie robię.
Chodzi mi o coś takiego, że t jest tylko Launcher, ten silnik, czy napisaną w nim funkcję będę mógł wimplementować w program gdzieś np.

Wreszcie wracamy do tematu.
Silnik to interpreter Rubiego rozwinięty o troszkę funkcji i bibliotek.
On zatem od razu ma w sobie audio, obsługę SAPI i tak dalej, aby tego nie pisać w Rubym, tylko w szybkim C.
Następnie tworzy, a raczej powinien tworzyć, bo to jeszcze nie działa, okno programu.
I tworzy wątek interpretera mainthread, w którym ładuje kod w Rubym i, co ważne, sprawia, że wykonuje się on tylko wtedy, gdy okno jest otwarte.
Tworzy też wątek agentthread, który może komunikować się z mainthread, w nim znowu ładuje kod Rubiego agenta.
I w ten sposób agent jest w jednym pliku i nie trzeba osobnego.
No i trzeci wątek to jest bgthread, do którego Elten wysyła wszelkie rządania, które mają działać w tle, jak konwersja plików itd.

Ale ja o co innego trochę pytałem.
Tworząc funkcję w C w samym silniku, nie wiem no... COkolwiek, comi na myśl przyjdzie czy będę mógł to wrzucić w główny program, czy nie?

Tak, ale musiałbyś ją umieścić w kodzie silnika i zainicjować w Rubym.
Masz tu przykładzik z silnika:

void EAPISpeech_INIT(VALUE mMod) {
VALUE mEltenEngineSpeech = rb_define_module_under(mMod, "Speech");
VALUE EltenEngineSpeech_say(VALUE self, VALUE saytext, VALUE outputtype, VALUE alter) {
#ifdef WIN32
if(outputtype==0)
sayString(StringValuePtr(saytext),alter);
else
sapiSayString(StringValuePtr(saytext),alter);
#endif
}
rb_define_module_function(mEltenEngineSpeech, "say", EltenEngineSpeech_say, 3);
VALUE EltenEngineSpeech_stop(VALUE self, VALUE outputtype) {
#ifdef WIN32
if(outputtype==1)
stopSpeech();
else
sapiStopSpeech();
#endif
}
rb_define_module_function(mEltenEngineSpeech, "stop",EltenEngineSpeech_stop,1);
VALUE EltenEngineSpeech_getvoice(VALUE self) {
#ifdef WIN32
return sapiGetVoice();
#endif
}
rb_define_module_function(mEltenEngineSpeech, "getvoice",EltenEngineSpeech_getvoice,0);
VALUE EltenEngineSpeech_setvoice(VALUE self, VALUE voiceid) {
#ifdef WIN32
return sapiSetVoice(voiceid);
#endif
}
rb_define_module_function(mEltenEngineSpeech, "setvoice",EltenEngineSpeech_setvoice,1);
VALUE EltenEngineSpeech_getrate(VALUE self) {
#ifdef WIN32
return sapiGetRate();
#endif
}
rb_define_module_function(mEltenEngineSpeech, "getrate",EltenEngineSpeech_getrate,0);
VALUE EltenEngineSpeech_setrate(VALUE self, VALUE vol) {
#ifdef WIN32
return sapiSetRate(vol);
#endif
}
rb_define_module_function(mEltenEngineSpeech, "setrate",EltenEngineSpeech_setrate,1);
VALUE EltenEngineSpeech_getvolume(VALUE self) {
#ifdef WIN32
return sapiGetVolume();
#endif
}
rb_define_module_function(mEltenEngineSpeech, "getvolume",EltenEngineSpeech_getvolume,0);
VALUE EltenEngineSpeech_setvolume(VALUE self, VALUE vol) {
#ifdef WIN32
return sapiSetVolume(vol);
#endif
}
rb_define_module_function(mEltenEngineSpeech, "setvolume",EltenEngineSpeech_setvolume,1);
}

Ehem.
Nie podoba mi sę to, no ale cóż. Lepsze chyba to, niż nic.

Ogólnie funkcję tworzysz tak, że najpierw definiujesz ją normalnie w C, przy czym wszystkie argumenty są typu VALUE, to Rubiowski typ parametru, a dodatkowo pierwszy parametr nieużywany pzez ciebie to self, a więc:
VALUE funkcjapiszacadokonsoli(VALUE self, VALUE copisac) {
puts(StringValuePtr(copisac));
return 0;
}
A potem ją rejestrujesz w Rubym
rb_define_module_function(uchwytmodulu, "nazwafunkcjiwrubym", funkcjapiszacadokonsoli, 1);
Ostatni parametr, tu 1, to ilość parametrów funkcji.