LINUX.ORG.RU

(ОБНОВЛЕНО) Тестовая версия авиасимулятора YSFlight ver.20181001

 , ,


1

1

Soji Yamakawa опубликовал свежую версию для тестирования бесплатного авиасимулятора YSFlight для 64-битных платформ Linux, Mac OS X и Windows (в вариантах для OpenGL1.x, OpenGL/ES 2.0 и D3D9)

Крайние стабильные сборки (в том числе и для Linux 32bit & 64bit) можно скачать здесь:

Также можно скачивать с сайта сообщества пользователей данного симулятора, где собраны все выпущенные версии YSFlight (начиная с 1999 года)

Просьба к пользователям Linux протестировать крайнюю тестовую версию на наличие багов и в случае их обнаружения написать отчет автору игры (in English, please).

Форум пользователей данного авиасимулятора:

★★★★★

В заголовке

ависимулятора

Radjah ★★★★★ ()

Ссылка на исходники где?

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

Ссылка на исходники где?

YSFlight это бесплатный (freeware) авиасимулятор для Linux и других ОС.

Но частично он базируется на opensource компонентах.

http://uk.wikipedia.org/wiki/YSFlight

Для этого симулятора есть свободный (free&opensource)кроссплатформенный 3D редактор PolygonCrest, основанный на том же opensource тулките, что и игра.

PolygonCrest (v20160221) - кроссплатформенный 3D редактор с функциями для создания моделей самолетов

atsym ★★★★★ ()
Ответ на: комментарий от atsym

YSFlight это бесплатный (freeware) авиасимулятор для Linux и других ОС.

Понятно, не нужно. Либо исходники, либо лесом. Ещё не хватало проприетарные трояны тестировать.

Ишь ты, ещё и свободным редактором тычет, совсем обнаглели...

slovazap ★★★★★ ()
Последнее исправление: slovazap (всего исправлений: 1)
Ответ на: комментарий от subwoofer

скриншоты?

Планировалось в этой тестовой версии добавить полутени, относительно положения солнца (в версиях для OpenGL/ES 2.0)

http://ysflight.in.coocan.jp/ysflight/ysflight/scrnshot/ss20161124-shadowMap-...
http://ysflight.in.coocan.jp/ysflight/ysflight/scrnshot/ss20161124-shadowMap-...
http://ysflight.in.coocan.jp/ysflight/ysflight/scrnshot/ss20161124-shadowMap-...

Скриншоты предыдущих версий (актуальная стабильная версия 20150425)

https://forum.ysfhq.com/viewtopic.php?t=27
https://forum.ysfhq.com/viewtopic.php?t=9103

P.S.: пользовательские сценарии/карты и транспорт выглядят в основном на много лучше стоковых (поставляемых с игрой, low-poly) дополнений.

atsym ★★★★★ ()
Ответ на: комментарий от slovazap

Понятно, не нужно. Либо исходники, либо лесом.

Лично тебя никто не заставляет даже смотреть на эту игру под Linux.

Ишь ты, ещё и свободным редактором тычет, совсем обнаглели...

Я указал на то что тулкит данной игры opensource, и на этом тулките еще построен opensource 3D редактор.

atsym ★★★★★ ()
Ответ на: комментарий от atsym

Лично тебя никто не заставляет даже смотреть на эту игру под Linux.

Вот пришёл некто к метро и начал героин продавать. Подходят к нему сотрудники, а он такой: «а никто не заставляет вас колоться». Не надо об этом мусоре сюда писать.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

Подходят к нему сотрудники, а он такой:

Факты «наличия героина» в этой игре под Linux есть? Или «сотрудники» планируют «подбросить пакетик»?

Форум «Games» - игры под Linux/Unix

Здесь обсуждают НЕ только полностью свободные игры под Linux, но и частично свободные и даже проприетарные. Все что может запускаться из под Linux.

Обмен ключами, скидками и прочими игровыми радостями (3)

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 2)
Ответ на: комментарий от atsym

Факт наличия героина - это факт отсутствия исходников.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

Факт наличия героина - это факт отсутствия исходников.

Конкретнее, пожалуйста. И по существу в отношении данной игры (YSFlight)

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

этьот ямакава по русски шпрехает? иль на японском надо отчет слать?

anonymous ()
Ответ на: комментарий от anonymous

Он нормально понимает на английском.

Если ты не можешь на английском написать, то напиши здесь на русском.

atsym ★★★★★ ()
Ответ на: комментарий от slovazap

Не надо об этом мусоре сюда писать.

запрещаешь что ли?

kott ★★★★★ ()
Ответ на: комментарий от slovazap

Да, не заставляет. Поэтому проходи мимо.

AVL2 ★★★★★ ()

Вышла тестовая версия YSFlight 20170517

Бинарники для Linux и Mac OS (в одном архиве)

http://ysflight.in.coocan.jp/download/YsflightForMacOSX-test-20170517.zip

Бинарники для Windows и WINE

http://ysflight.in.coocan.jp/download/YsflightForWindows-test-20170517.zip

2017/05/17

  • Config: Draw runway lights during the day «only if the visibility is less than XX miles»
  • Draws flare and black smoke with particles.
  • Draws clouds with particles in YSFLIGHT on OpenGL 1.x and Direct X9
  • Vary point size for aircraft lights depend on the window size (it was fixed 3 pixels.)
  • I forgot copying sound DLLs for Linux. Now it is in.
  • Sorry, I haven't been able to address all the bug reporst. I'll try to get them done in the next update.
atsym ★★★★★ ()

Вышла тестовая версия YSFlight 20170923

2017/09/23

  • Draws smoke trail (of airplanes and missiles) with particles if use-particle option is on. If the new version is too slow due to massive particles, turn off this option to draw clouds with polygons.



2017/09/10

  • Added Cessna 172.


Бинарники для Linux и Mac OS (в одном архиве)

http://ysflight.in.coocan.jp/download/YsflightForMacOSX-test-20170923.zip

Бинарники для Windows и WINE

http://ysflight.in.coocan.jp/download/YsflightForWindows-test-20170923.zip

Обсуждение

https://forum.ysfhq.com/viewtopic.php?f=285&t=9461

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

Принес тебе православненького - http://askmisterwizard.com/FlightSimMovies/LAC/LacIntroFullPage.htm

только что свеженькая версия вышла. сорцики открыты, всё как мы любим. А проприетарщину ты уноси отсюдава. нехорошо пропритарь тащить на уютненькое, нехорошо...

anonymous ()
Ответ на: комментарий от anonymous

Принес тебе православненького

Ты не поверишь, но новость о LAC на ЛОР принес впервыя именно я

Linux Air Combat — новый авиасимулятор

И сам разработчик LAC является фанатом YSFlight и вдохновляется им ('bbosen' это его ник на форуме пользователей YSFlight)

https://forum.ysfhq.com/viewtopic.php?t=8496

http://askmisterwizard.com/FlightSimMovies/YsFlight/TechVideoReviewYsFlightSe...

P.S.:

тащить на уютненькое

Повторю

(ОБНОВЛЕНО) Тестовая версия авиасимулятора YSFlight ver.20181001 (комментарий)

atsym ★★★★★ ()

YSFlight 20171030 Test

CHANGELOG – http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

  • Fixed shadow-map in the aircraft-selection screen. (It took a while, but I just forgot enabling GL_DEPTH_TEST and unmasking GL_DEPTH_BUFFER after drawing widgets.)
  • Fixed NearZ in additional cockpit views.
  • Zoom/Unzoom with mouse wheel even when Windows reported rotation count smaller than the unit count.

СКАЧАТЬ:

ОБСУЖДЕНИЕ – https://forum.ysfhq.com/viewtopic.php?f=285&t=9492

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

YSFlight 20171217 Test

CHANGELOG – http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

2017/12/22

  • Bug fix: Change of «Default Field» in the config dialog was not updating the starting points.
  • Bug fix: «NO CLOUD» option was ignored.
  • Bug fix: Full-Screen setting was ignored after restart.
  • Bug fix: Fly-Heading-Bug auto pilot was ignoring magnetic variation.
  • Bug fix: ATC's heading instruction was ignoring magnetic variation. (I think I fix it. Hope I didn't break it.)
  • Bug fix: Starting-Position search text box in New-Flight Dialog was not functioning. Selection changes, but not really selected.
  • Bug fix: Aircraft DNM not initialized in the aircraft-selection dialog.
  • Air Racing Mode (Still in the middle of making).
  • Implemented Endurance Mode, Intercept Mission, Ground-to-Air Mission, Close-Air-Support Mission as an extension. The first goal is to reduce the running modes of the program into 5 modes: GUI, Flying, Replay, Server, and Client. Those missions used to be an independent mode, which was making the program very difficult to maintain. Eventually I want to make Server and Client as an extension, but that's the next stage.

I learned a lot about C++ programming through YSFLIGHT. That means in many places, I learned a better practice, which improved my research / work code, but it was too late for YSFLIGHT. Also known as code debt. I am cleaning those mess.

With this change, I still have three additional modes to turn into an extension. So, if you can help me debugging it, I'll appreciate if you can fly a few times of those missions.

DOWNLOAD:

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 2)

YSFlight v20180314 & SceneryEditor v20180314 (test, unstable)

CHANGELOG - http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

2018/03/14

  • Can put SRF models in FLD. (Can be done from the Scenery Editor). Very long time ago, FLD had this feature but the collision was checked against the bounding box. In this update, the collision is checked per polygon. I really wanted to add field-specific ground object, but anyway SRF in FLD is also needed for complex terrain.
  • Bug fix: If a DNM model defines rotation based on STATE 0, new data structure was not transforming it as intended. Sorry, I was not clear about which of no-transformation or STATE-0 is the base orientation. I was thinking to make it no-transformation, but looks like there are many models that are assuming STATE-0 is the base. I'm leaning toward making STATE-0 as the base orientation.
  • Bug fix: Fireball renderer was not clearing Emissive color in D3D9 code.
  • I'm also experimenting with unit-test scripts. So far I was able to automate selecting all items in Simulation menu, selecting all default fields, and some config items. I need to automate testing file menus and network features.

DOWNLOAD YSFlight v20180314

DOWNLOAD SceneryEditor v20180314

atsym ★★★★★ ()

YSFlight 20180422 Test

CHANGELOG – http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

2018/04/22

  • Separated ILS view (default F6) and Tower view (default F8).
  • Looks like a standard definition of magnetic variation is West=minus and East=plus. I was calculating opposite. I reversed it to align with the standard. Thank you for pointing it out!
  • Fly -> Select Aircraft -> Fly -> Retry Previous Flight was resetting the aircraft to the first player aircraft. Now it will start in the last aircraft.
  • Auto-Test script

СКАЧАТЬ:

ОБСУЖДЕНИЕ – https://forum.ysfhq.com/viewtopic.php?f=167&t=6036

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

YSFlight 20180519 Test

CHANGELOG – http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

2018/05/19

  • I think this time I really fixed the magnetic heading and true heading consistency. By the way, I made the sign back to the previous. (In YSFLIGHT West is positive.)
  • ARTCC was not giving higher than 10000ft, which was awkward for a long cross country in a jet airplane. Now it gives up to the altitude specified in the aircraft data.
    (Actually, the descending instruction was supposed to be given +6000, +3000, and then +1500 of the destination airport, but for some reason the current ATC skips +3000. I'm looking into the problem.)

СКАЧАТЬ:

ОБСУЖДЕНИЕ – https://forum.ysfhq.com/viewtopic.php?f=167&t=6036

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

YSFlight 2018 coming soon...

>>> http://ysflight.in.coocan.jp/main/e2018.html

2018/06/20

(...)

Here's one news. I was porting my libraries to Android. Hopefully I can talk more about mobile programming in the spring semester course. YSFLIGHT kernel runs on Android now. It's not quite playable, but I am thinking to make a YSFLIGHT player for running demos and re-playing what you record in a PC. I set my goals of the summer as:

  • (...)
  • Make YSFLIGHT 2018 official stable release.
  • Release YSFLIGHT Player for Android and iOS.

That's what I was thinking to do, when Apple dropped a bombshell.

OpenGL and OpenGL ES will be unavailable in macOS and iOS in the future OS versions. I was somewhat expecting it when Apple announced Metal. At the same time, I was hoping Apple to maintain relatively higher-level and standard graphics APIs. The expectation was shattered into pieces by this announcement.

Microsoft tried to drop OpenGL in Windows Vista once. Then developers around the world criticized the decision, and Microsoft withdrew the idea. OpenGL is, although officially up to version 1.1, still supported as a part of Win32 API. In Universal Windows Platform Microsoft implemented OpenGL ES 2.0 on top of Direct X and therefore is still part of the Windows API. But, probably Apple won't listen.

At least OpenGL should be available for a while, there is a possibility that YSFLIGHT is not available for Mac and development for iOS suspended at least for a short time.

I'm looking into Vulkan API by the way. One of the big problems of current programming is, in my view, that the graphics API has too much influence on the program and data structures. I see a lot of «to extract the best performance from GPU» while I read through Vulkan documentations and tutorials. Tell you what I want to say to them? «Shut the mouth up.» I am not competing a Hollywood movie. I won't need the maximum performance from GPU. I rather want to know cleaner and maintainable way. I personally believe correctness and maintainability is more important than performance.

atsym ★★★★★ ()
Ответ на: комментарий от nvl

F-22 RAPTOR, один из ~ 90 стандартных (low-poly) самолётов поставляемых в комплекте с YSFlight и, можно сказать, наиболее прокачанный стандартный самолёт.

Файлы этого самолёта:

./YSFLIGHT.COM/aircraft/f22.dat
./YSFLIGHT.COM/aircraft/f22.dnm
./YSFLIGHT.COM/aircraft/f22coll.srf
./YSFLIGHT.COM/aircraft/f22cockpit.srf
./YSFLIGHT.COM/aircraft/f22_coarse.dnm

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 3)
Ответ на: комментарий от atsym

nvl, а вот, для сравнения, созданные пользователем decaff_42 дополнительные модели самолётов F-35 Lightning II (в модификациях F-35A, F-35B, и т.д.), которые являются образцом HQ-дополнений (high-poly) для YSFlight

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

YSFlight 20180704 Test & SceneryEditor 20180704 Test

>>> http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

2018/07/04

  • I'm thinking to start pre-release test based on this version.
  • Fixed VOR OBS indication. (I should make a Pittsburgh map so that I can positively check heading/OBS indications...)
  • Scenery Editor: Prevent Color-Palette Dialog disappearance.

DOWNLOAD:

atsym ★★★★★ ()

Auto-Test Scripts + install_addon.py (opensource, BSD License)

Soji Yamakawa пишет:

http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

2018/08/02

  • I don't know if it is useful for someone, but I have uploaded a set of test scripts. It is significant for me because more than half of pre-release test items are covered by this batch. (Such as selecting random menu items or changing configurations and make sure the program does not crash) Also I have automated installing the add-on packages to a test-environment and flip through airplanes and maps. Actually that was fun. I was impressed by the variety and the quality of the models. I used to be randomly selecting a few packages before. This revealed many mistakes in my code, which should be fixed shortly.
  • By the way, install_addon.py is free on BSD license. Please feel free to customize and bundle with your add-on packages. This might be useful.

DOWNLOAD:

atsym ★★★★★ ()
Ответ на: комментарий от atsym

сайт

скриншоты

Эээх, прям как из середины 90ых... Как глаток свежего воздуха в мире yoba и смартфонных вебдевов...

Deleted ()
Ответ на: YSFlight 2018 coming soon... от atsym

Re: YSFlight 2018 coming soon...

Soji Yamakawa пишет:
>>> http://ysflight.in.coocan.jp/main/e2018.html

  • 2018/07/14Vulkan

    I've been learning Vulkan API for the last a few weeks. I feel that I have enough knowledge to port YSFLIGHT to Vulkan. When the doomsday comes, when OpenGL is no longer cross platform, I should be able to switch to Vulkan.

    That's only if Vulkan gains popularity as advertised. I have a serious doubt if it will be well adapted though. The reason why I am worried about the Vulkan adaption is because it is not taking over OpenGL. It is trying to take over extreme low-level APIs like Direct 3D and Metal. I don't think Microsoft and Apple are happy with Vulkan. Apple is openly unhappy with Vulkan. It also takes over OpenCL, which gives nVidia a reason not to be supportive. If Vulkan takes down OpenCL, and the Vulkan itself fails, nVidia will dominate the GPU processing by CUDA. Those big companies, except Apple, are saying they support Vulkan, but they may just be pretending.

    Already I see signs that Vulkan is buckling. Since Apple totally ignored Vulkan, they arranged a deal to get MoltenVK, Vulkan implementation on Metal for Apple platforms, open-sourced. But, it is only a subset of Vulkan. It lacks the Validation layer. Vulkan has too many knobs to control. You cannot tell if you are feeding correct parameters.. The Validation layer will tell you when given parameters are outside of the Vulkan specification. It is virtually impossible to develop without the Validation layer. You may get something working in your environment without the Validation layer, but your program may not work when you take it to another platform.

    So what I have been doing is writing code on my Mac mini home, and the next day I test the same code on Windows on my office PC to see a bunch of error messages from Validation layer then only I can correct them. Why can't I debug at home? Because of Intel's reluctance in Vulkan, none of my ThinkPads running Windows 10 can run Vulkan. My ThinkPad X250 is just 3 years old, but it is too old to run Vulkan. In a sense, Vulkan doesn't run on too many integrated GPUs and is nothing cross-platform yet. Since Vulkan runs on those older integrated GPUs on Linux, there is no reason it cannot be done on Windows. I don't know what Intel is holding off.

    The shader program of Metal seems to be less capable than SPIR-V. The output from the vertex shader ( varying in the OpenGL term) cannot be an array or a matrix. (Come on, Apple!) That is supposed to be a Metal problem, not a Vulkan problem, but MoltenVK inherits the problem since it is implemented on Metal.

    Therefore, the shader that runs perfectly on Windows may not run on macOS and iOS. Because of this hiccup (plus more hiccups), Khronos is now talking about official Vulkan 'subset'. Aaaagh! What's the point of the standard?

    By the way I think GLSL to SPIR-V compiler that comes with the LunarG package has a bug. If I write:

    layout(std140,set=0,binding=0) uniform State
    {
    mat4 projection;
    // 16-byte alignment
    vec4 lightEnabled;
    everything works. But, when I was writing it as:
    layout(std140,set=0,binding=0) uniform State
    {
    mat4 projection;
    // 16-byte alignment
    float lightEnabled[4];
    Everything after lightEnable[0] were zero in my shader. Only lightEnabled[0] receives a correct value from my C++ program. I checked every single line in my code, counted bytes to make sure 16-byte alignment, and could not figure why my shader didn't receive any value after lightEnabled[0]. In a desperate attempt, I changed float[4] to vec4, and everything worked. I found no explanation why vec4 worked and float[4] didn't. I hope it is a bug, not a mysterious specification that nobody understands.

    Speaking of uniform, to set a uniform value in Vulkan, you need to first copy values to a uniform buffer, which is supposed to be already in the GPU memory, and then uniform buffer "written" to the VkDescriptorSet, which then can finally be bound to a binding point of a VkDescriptorSetLayout and become visible to the shader program (or pipeline in Vulkan term).

    My question: Isn't VkDescriptorSet unnecessary?

    Although I «write» the content of a uniform buffer to a VkDescriptorSet, a VkDescriptorSet looks to be just a pointer to a uniform buffer or a sampler. I don't see any point to make VkDescriptorSet an allocated resource. It should be possible to bind a uniform buffer or a sampler directly to a VkDescriptorSetLayout.

    In the current version of Vulkan, you need two resources, a uniform buffer and a VkDescriptorSet to bind a uniform. (If you count a uniform buffer and a uniform buffer memory separately, three resources.) Since VkDescriptorSet is no more than a pointer, it should be small enough to be carried in a command buffer. Allocation of VkDescriptorSet is a utter waste. I hope the next version of Vulkan includes a function that directly binds a uniform buffer or a sampler to a binding point of a [inlime]VkDescriptorSetLayout. For the time being, I allocate a uniform buffer and a VkDescriptorSet always as a pair, and my code looks to be working fine.

    Anyway, I am hoping one of the two things to happen: (1) Vulkan gains momentum as promised, or (2) someone writes an OpenGL implementation on Metal (actually there is a commercial library called MoltenGL, but I cannot afford.) If Vulkan gets popular, I'm fine. I can continue coding cross-platform with Vulkan. I have already seen some problems, but it also is free from some OpenGL's problems. First of all, I appreciate its type safety. Every object in OpenGL was an unsigned integer. A compiler didn't catch if I was giving a texture name as a vertex-buffer name. It would take several months to a year to port my OpenGL code to Vulkan if I need to, but doable. Or, if OpenGL continues to be available on Apple platforms, it maintains its value and stay alive for longer period.

    My worst fear is that Vulkan fails, OpenGL fades, and no cross-platform graphics API. I might look into Unity or Unreal engine, but those are basically for commercial development. I admire Unity's effort to keep backward compatibility, but still there is a license clause saying I need to pay some fraction of earning when the product is commercialized. Some of my research code have been used not as a consumer products, but as a part of the deliverables for industry-sponsored projects. Of course it is a part of an academic research project, but it is somewhat gray area that I don't want to step into. If I code for an industry-sponsored project using Unity or Unreal, I need to talk to an attorney who is specialized in the intellectual property laws to make sure there is no problem, and I don't have money to do so.

    I expect Khronos would say something during SIGGRAPH 2018, which will be next month. I keep eye on what they say.

atsym ★★★★★ ()
Ответ на: Re: YSFlight 2018 coming soon... от atsym

Soji Yamakawa пишет:
>>> http://ysflight.in.coocan.jp/main/e2018.html

  • 2018/09/25macOS Mojave nuisance

    One of my students emailed me saying OpenGL stopped functioning when he updated his macOS to 10.14 Mojave. I was caught by surprise because Apple was stating that OpenGL still functions although it is labeled deprecated. Did Apple break promise again? Is it something I was worried about? I also updated my mac mini and confirmed the problem.

    It's already almost one month into the semester. I didn't want to tell all my mac-user students to hold off the OS update or use Linux or Windows at this point. After several hours of investigation, I found that all OpenGL drawing outside of drawRect method of NSOpenGLView are ignored in macOS 10.14. (As far as I tested, all OpenGL function calls outside drawRect and prepareOpenGL look to be ignored.)

    For example, your program may be calculating one step of the motion and re-drawing at the end of the same function which is outside of drawRect, then your program may stop functioning in 10.14. Or if you are initializing OpenGL states outside of prepareOpenGL, the state may not be initialized at all. The same limitation used to apply only when NSOpenGLView had a sub-view. But, apparently macOS 10.14 applies this limitation regardless of the presence of a sub-view. I am glad at least I knew about the limitation of NSOpenGLWindow with a sub-view. If I didn't know about it, I could have been in the dark now.

    I am teaching an introductory programming. I wanted to avoid dealing with call-back functions, but it looks to be unavoidable. I'll explain in class tomorrow.

    I hope Apple to support OpenGL longer, but nobody except Apple employees knows how long OpenGL runs on macOS. How can I teach introductory graphics programming with Metal? Metal is useless unless a student is looking to apply for a position in Apple. If I cover up some hard-to-understand part of Vulkan, I think it is possible to go with Vulkan, but Vulkan has its own problem. Vulkan is still not cross-platform yet. I have three computers home, and Vulkan doesn't work on two of them. It is somewhat understandable it doesn't work on 5-year old ThinkPadX230T, but Vulkan doesn't run on my 2.5-year old ThinkPad X250, either. 3-year old computers are still everywhere. If Vulkan doesn't support 3-year old Intel GPUs, it is not yet eligible to be called a cross-platform. Are they going to ignore 3-year old Intel GPUs? Khronos may say it's Intel's problem, not Vulkan's problem. From the user's and developer's point of view, Vulkan is not running on too many computers no matter whose problem it is. I doubt about the seriousness of the people who are working on Vulkan. Vulkan has a good chance of failing. In fact, it is not taking over OpenGL. It may already be failing. Vulkan gave an excuse to Apple for dropping OpenGL. Other operating systems may follow. Then Vulkan itself may disappear. There is a high probability of programmers' dystopia where no cross-platform graphics API exists.

atsym ★★★★★ ()
Ответ на: комментарий от atsym

Soji Yamakawa пишет:
>>> http://ysflight.in.coocan.jp/main/e2018.html

  • 2018/09/28Vulkan the future or failure?

    The undocumented changes in OpenGL-handling of macOS 10.14 created some extra work for me. I need to modify sample codes for my teaching. Each change is small, but I have many source files. I also need to update explanation on my course notes.

    There is no explanation of the changes. If the program is not calling OpenGL functions outside prepareOpenGL and drawRect, it should work fine. Otherwise, the program won't work on macOS 10.14. I can imagine programs registering textures in arbitrary locations. The current official version and the test version of YSFLIGHT does not run on macOS 10.14, either. The new stable version will be out soon, which runs ok on macOS 10.14. I have already fixed my code. YSFLIGHT is running fine on macOS 10.14 running on my mac mini. I originally was planning to push it out by the end of the summer break but couldn't finish pre-release tests in time, and pre-release test is now slowly moving forward. But, it worked out well for macOS 10.14.

    But, the removal of OpenGL from macOS is becoming more realistic. To prepare for the transition to Vulkan, I was reviewing my Vulkan test codes that I wrote in July. OK. I was able to do shadow mapping. That refreshed what I studied. I think I can use Vulkan if I choose to.

    Yes, I am confident in coding with Vulkan. But, probably only few developers can understand and use this API. Vulkan is an EXTREMELY difficult API. Exponentially more difficult compared to OpenGL. Years ago, we had tough time transition from OpenGL 1.1 regime to OpenGL ES 2.0 regime because ES 2.0 made GLSL mandatory. But, the difficulty of Vulkan is way too much more than that. It requires unreasonably low-level programming and micro-management of GPU. OpenGL somewhat provided the rendering model, but Vulkan gives nothing. Vulkan dumps all the responsibility on the application programmer. Probably less than 1% of the programmers who can write OpenGL ES 2.0 code can develop on Vulkan.

    After Vulkan is out, there are so much developers who are worried about the future of OpenGL. Vulkan started as the next-generation OpenGL. It is very much understandable. No matter how loud Khronos shouts that they maintain OpenGL, it is too late to extinguish those anxiety.

    I had once used an API called IRIS Performer. I think it was in 1994. IRIS Performer was developed by Silicon Graphics who was the leader in the 3D graphics industry that time. My then advisor wanted to see if IRIS Performer was useful. IRIS Performer was made public when the computer-graphics community came up with an idea of Scenegraph. The idea was that the graphics API can optimize rendering operation if the entire scene structure, rather than a soup of lines and triangles, is registered to the API. But, in IRIS Performer, the registration was difficult like hell. Sure, if I transfer that much rich information to the API, it should be able to fully optimize the rendering operation. But, it was too difficult and impractical. That was our conclusion. Other people soon stopped talking about it, and IRIS Performer was forgotten. Silicon Graphics was wonder-straying off course in developing a scene-graph API, and they then released a new API called Cosmo 3D, which quickly disappeared by itself. Developers lost confidence on Silicon Graphics, and it lost the dominance.

    I see so much of similarity between IRIS Performer and Vulkan. Sure, if I go down that low level, I may be able to fully tune the rendering pass for maximum performance. But, virtually nobody will be able to program Vulkan, except handful programmers. People saw IRIS Performer as the next-generation 3D graphics API at first. We thought 3D-graphics then-giant, Silicon Graphics, must have created a very good API. People gave up quickly because it was unreasonably complex and extremely difficult. Because nobody used, people stopped talking about it. It disappeared by itself. My very unscientific survey is indicating that more people are complaining about extreme difficulty of Vulkan than appreciating its performance. If only few people uses it, it would disappear. Just as Silicon Graphics lost trust from developers, people will lose confidence on Khronos. Didn't Khronos learn from the failure of IRIS Performer? ... Maybe young people haven't even heard about IRIS Performer.

    As if Khronos totally lost their mind, they started Vulkan Portability Initiative. For many of us, the problem is how we can transition to Vulkan. It is virtually impossible to transition our current code base using OpenGL to Vulkan. It helps nothing about our problem. This portability initiative, for an unknown reason, is done in a programming language called Rust. I've only heard about it. Just skimming the code, I got an impression that it was another lesser copy of C++. New programming languages are irresponsibly created and thrown away. That's a serious problem of computing today. Looks like this portability initiative is not going anywhere. It has been stopping since last year.

    The situation, almost 100% re-enactment of IRIS Performer, makes me hesitate to transit my code base to Vulkan. It happened before. I spent quite good amount of time to learn DirectX9, and partially added support in my projects including YSFLIGHT. Then Microsoft dropped the backward compatibility in DirectX10. Learning DirectX9 was made utter waste. I felt so dumb. I'm glad I didn't waste time to learn DirectX10 because Microsoft cut the backward compatibility again in DirectX11. I'm done with DirectX. I don't want to repeat the mistake again. Because at this time I see very good probability of Vulkan to disappear, I cannot invest more time for Vulkan. Well, another reason is it still doesn't run on my ThinkPad X250 and X230T. Is Vulkan cross-platform? No. It's a fake news! There still are very large quantity of Windows PCs that are running on 4th- and 5th-generation Core processors and built-in GPU. Vulkan is failing to reach out to those population.

    In my view, there is only one way out for Khronos from the failed attempt of Vulkan. Implement OpenGL on top of Vulkan, release it as a reference code, and maintain it. OpenGL is not that unreasonably crazy low-level as Vulkan. It makes sense to implement OpenGL on top of lower-level API, and it should be very much doable. Of course, the performance will be sacrificed because the GPU and application gets somewhat farther apart by the OpenGL layer.. But, what I am looking for is maintainability and reasonably easy coding. OpenGL, especially 1.1, is so good for quick prototyping. Vulkan is not. OpenGL 1.1 is so nice to get students started. How can I teach Vulkan to my students? It is impossible. I think implementing OpenGL layer on top of Vulkan is the only way for Khronos to re-gain confidence from developers. No matter how much Khronos insists that they continue OpenGL, we won't trust unless they actually act.

atsym ★★★★★ ()
Ответ на: комментарий от atsym

Soji Yamakawa пишет:
>>> http://ysflight.in.coocan.jp/main/e2018.html

  • 2018/09/29macOS 10.14

    Looks like I was stepping on another landmine of macOS 10.14, which destroys cached NSMutableDictionary somewhere. I could look into it deeper to pin-point exactly where it is destroyed, but I don't want to waste no more time. My font-renderer was using a cached NSMutableDistionary, but I changed so that my font-rendering function allocates and releases a NSMutableDictionary every time it is called. It is inefficient, but didn't make any visible loss of performance, and works on macOS 10.14.

    But, the error was caught during unit tests. I am glad I spent time to set it up.

    ... How can I tell if I addressed all undocumented changes in macOS!? I did run my unit tests, but I cannot think my tests cover everything.

    Actually, my iPhone 5S no longer charges from PC USB port after upgrading to iOS 12. I need to use a larger-output (like 2.4A) USB charger. I don't think I had a good luck with OS upgrades from Apple this time.

    YSFLIGHT

    Actually, the fix for macOS 10.14 actually influenced the other part of the code bigger than initially expected. YSFLIGHT is running on macOS 10.14 somewhat ok, but it broke Windows and Linux versions. I think I fixed mostly, and a few more steps to go. But, I'll make another test version before running the pre-release test all over again. I'm going to upload a new test version soon. I wish the new version of macOS hadn't happened.

  • 2018/09/30My First Logbook Completed!

    I have been fixing YSFLIGHT code cursing macOS 10.14. But, today I took a nice break from a frustrating task and flew from Beaver County, completing my first flight logbook! (Read more)

atsym ★★★★★ ()

YSFlight 20181001 Test Version (pre-release)

Soji Yamakawa пишет:
>>> http://ysflight.in.coocan.jp/ysflight/ysflight/testvere.html

2018/10/01

  • Corrected OpenGL 2.0/ES 2.0 rendering error.
  • Support macOS 10.14. Actually I had to make more-than-expected corrections in user-interface. Please let me know if you find some strange behavior in the UI.

СКАЧАТЬ:

ПРИМЕЧАНИЕ: Это (возможно) последняя тестовая версия перед грядущим релизом, поэтому если вы находили баги в предыдущих тестовых версиях в за период 2017-2018 годов и в 20181001 Test Version эти баги до сих пор проявляются, пожалуйста, сообщите о них разработчику.

Архив всех предыдущих версий:

atsym ★★★★★ ()

¯\_(ツ)_/¯

Soji Yamakawa пишет:

http://ysflight.in.coocan.jp/main/e2018.html

  • 2018/10/08

    Decentralization?

    When I saw the blog-hosting services, I didn't like it because of inability to keep a local back up. Some seemed to be offering a capability of taking a local back up copies, but then what about restoration? What if they terminate the service? Is it easy to transfer my blog to a different service? Looked to be hell difficult. I didn't buy them. I am stubbornly using an old-school web site.

    When I saw Social Network Services like Facebook, MySpace, and Mixi, I wondered why people do what they can do with a personal web site with less control. I also am bothered by the inability to take a local back up and restoration. The contents of my web site is mine. I sacrificed money, time, youth, social life, and hair to learn programming. Why do I have to give away my contents and let them make money? I do have a FaceBook account. But, I'm using it just as an automatically-updating address book. I will never ever upload anything to FaceBook.

    When I saw GitHub, I was frightened by every open-source projects concentrated in one web service. If I were an evil programmer, here's what I would do. I would hack into a source repository and then inject a malicious code into a source code of a very popular software title. Next time the build from that repo is released, the official copy of the title will distribute my code for me. Now everyone uploads code to GitHub, such a hacker knows exactly where to target.

    Therefore I am still stubbornly keeping my own private repository local.

    What's common about above my concerns are the centralization. Everyone tries to lock you in to their service and make hard to leave. I was thinking I was only one person who is concerned about the centralization. Surrender of controls over contents, not just private information. The trend was not going to the right direction in my view. People talk about problems of those SNSes, but nobody seemed to be concerned about getting locked in to a specific network.

    Apparently, someone else does have concern. A famous guy. I 100% agree with the philosophy of the Solid project.

    https://solid.mit.edu/ (Hmmm, I cannot agree more to their philosophy, but they are hosting the sources in GitHub.)

    Right now I have problem in how to make my open-source part of my code public. I haven't been able to release them in a timely fashion because I always get higher-priority tasks than making and testing a release package. I rather want to open read-access to my public repository to public. GitHub for sure will host my open-source projects, but I don't want to be a part of the centralization. I'm looking into the Solid project to see if it can solve my problem.

    So, I created my POD, but I haven't been able to do anything useful yet. Maybe it does not work with Firefox.
atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)
Ответ на: ¯\_(ツ)_/¯ от atsym

Re: ¯\_(ツ)_/¯

Расскажите ему уже про гитлаб и сорцфорж кто-нибудь наконец. Хотя уже после его нытья по поводу гейос и убогих железок думаю всё понятно было. Сколько ему лет? Почему он такой маразматик?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.