I bought a classic game called "Dragon Slayer" for my Fujitsu Micro 7 from Yahoo auction. There were two versions of Dragon Slayer for FM-7, one in a floppy disk and the other in an audio cassette tape. The floppy-disk version is nearly impossible to find. The one I bought was in an audio cassette tape.
This game was very famous and popular in Japan back in early 1980s. I did play, but it was too difficult for me. I didn't know that the map is connected left and right. To get a sword visible on the right at the beginning, I was supposed to walk left. I just couldn't find a route to get to the sword then.
I bought the audio cassette media not because I wanted to play again, but I was more interested in restoring it to the working condition. Actually, the restoration to the .WAV file was successful with little difficulty. Once restored, I wanted to confirm it is complete, i.e., that I could play through. But, the audio-cassette version has only one map where the disk version has multiple maps. Then came to my mind was an emulator-based PC port called "Dragon Slayer Chronicle". The package included Dragon Slayer, Xanadu, Xanadu Scenario II, and other Dragon Slayer series titles. I purchased it a few years ago, and played Xanadu and Xanadu Scenario II, but I hadn't played Dragon Slayer. The version in the package was from PC-8801 disk version.
So, it already had nothing to do with the original purpose, but I started Dragon Slayer for PC-8801 that came with "Dragon Slayer Chronicle". I have 2D Retromap Tool. Also I can save the state anywhere since this one is emulator-based. I couldn't finish it back then, but I now should be able to play through.
I didn't know how many stages (called Phase in Dragon Slayer) I needed to go through at the beginning. I was guessing it should be somewhere around 10. But, as I finished phase after phase, I encountered a new phase. I couldn't save looking at a hint online, and knew there were 20 phases in total. I nearly gave up.
But, I finally played through the last phase, 20th, or Phase K today. I played through all variations of the maps. Then the game goes back to phase 1 with slightly stronger enemy monsters, but I'm not interested in playing all over again.
It had some element of puzzle solving, also it needs a strategy. Now I understand why this title made such a big hit. Actually, the sequel title "Xanadu" sold a then-unprecedented copies, many users started with Xanadu. I was one of them. I played Xanadu before Dragon Slayer. But, I regretted that I had never been able to finish Dragon Slayer yet. Now I played through PC88 version. I fulfilled another long-unfinished business.
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
// 16-byte alignment
everything works. But, when I was writing it as:
layout(std140,set=0,binding=0) uniform State
// 16-byte alignment
Everything after lightEnable were zero in my shader. Only lightEnabled 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. In a desperate attempt, I changed float to vec4, and everything worked. I found no explanation why vec4 worked and float 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 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.
FM-7 Resurrection Utility: I was compiling in Debug mode. I re-compiled in Release mode and updated the binary.
Carnegie Mellon University is in summer break. I was visiting Japan after seeing off my students in the commencement, came back, went to Niagara Falls air show, and back in Pittsburgh. I'm going to Dayton Air Show this weekend, but the weather doesn't look to be promising.
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:
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.
RAM Smart Phone Yoke Mount
I have tried RAM X-Grip Smart Phone Yoke Mount. (Read more)
I've been asked when I release the next stable version. Sorry. I haven't been able to take time for pre-release test because I spent too much time for retro RPGs. Actually YSFLIGHT grew feature-rich a lot more than I was originally expecting and it is very difficult to manually test many of these features. So, one of the effort I am doing is to automate such tests. I tried several different ways, but the latest scripting is working nicely. For example, now I can automatically select all of the Simulation menus or I can automatically select all of the default aircrafts and fields in the new-flight dialog to make sure the program does not crash. It is amazing to see my test scripts go through many test items for different versions of YSFLIGHT in a few minutes that were taking more than an hour.
Also I am able to test with some different configurations. The work load for the testing will substantially be reduced if I am able to automate tests of many of the configuration items. But it cannot detect the crash, so I need to be in front of the monitor. That's one of the remaining problems.
Looking back, I have added so many features compared to the current stable version. It is a good time to take time for pre-release test and make it official.
I also spend some time occasionally for at least making YSFLIGHT auto-demo for iOS and Android. But, the major road blocking is I need to set up build separately for those two platforms. I cannot really type "cmake ~/development" to set up build environment.
I had a feeling that I forgot something....
Turned out I was totally forgetting about a meeting.
When I am writing a paper or a code it is too easy to forget about time. Also it is easy to lose track of what meetings I got and what meetings are cancelled. If I muted my iPhone for my class and forgot unmuting, things get out of control.
I'm really curious how other people mage their schedule while writing papers and codes, teaching a class, and attending hundreds of meetings.
Closing of Forward Lanes
A bowling alley in Squirrel Hill that I have been bowling for nearly two decades closed the door permanently last weekend. According to a newspaper the place had been open since 1924. So, the place had nearly a century of the history. I visited Forward Lanes for the first time in 1998 when I came to Pittsburgh as a Ph.D student. I was not a frequent bowler while I was a student, but after getting my degree and started as a research associate I moved to an apartment one-minute walk from Forward Lanes. Then I started bowling more frequently.
Bowling is only one sports that I can do better than average people. Though I didn't have an ambition to bowl in a league then. I just wanted to stay above average. I often went there alone and bowled eight games in a row for practice. One day then-owner of Forward Lanes saw me practicing and suggested me to join a league. I never knew it was so easy to join a league. I happily joined the Saturday-Night League, then-called Young Adult League. That was I think in 2004 or 2005. So, I bowled in the league for almost 14 years.
Although it was not a serious league at all I was still honored to be the highest-average bowler for several seasons. Recently Forward Lanes started cutting down oil on the lanes and made the condition favorable for fast and power bowlers. No matter what I tried I never gained my ball speed. My ball was hooking too much in the recent Forward Lanes' oil condition and never bowled as good as before. Which was fine. My primary league nowadays is Thursday Bowlmor Classic at Brunswick Zone Playmor Bowl in West Mifflin. This is a sanctioned league filled with serious bowlers. I bowled 259 (625 series) there yesterday by the way. So I do not lose a place to bowl. But, closure of a bowling alley that I had been bowling such a long time made me sentimental a bit.
By the way this is the score from my last game in Forward Lanes.
FM77AV / AV40 Resurrection Project: Infra-Red wireless keyboard emulator
If you are a classic-computer lover, and if you want to get a FM77AV or FM77AV40 unit from Japan, like Yahoo! Auction, you can often find a unit in a good condition. But, for some reason, most unit doesn't come with a keyboard. In such situations, this Infra-Red wireless keyboard emulator can help. (It is not for FM77AV20EX/40EX/40SX which does not have an Infra-Red sensor.)
FM-7/77 series resurrection utility
If you happen to own a Japanese retro PC called FM-7/77 series with a disk drive, and your original floppy disk went bad but you have a back up disk images in .D77 format, these utilities might help writing disk image back to a fresh floppy disk.
Happy New Year!
I was staying in San Francisco during the break, came back in an overnight red-eye flight, and then caught cold.
We were there to eat fresh seafood there. Typical Japanese tourist visiting San Francisco probably would visit more touristic places, but we were there for food. We are living in Pittsburgh and starving for fresh seafood.
I stayed there for four days, and rented a Cessna 172 on the last day to fly a Bay-Tour course with an instructor. I was unfamiliar with the airspace around SFO, and the airspace is much more complex than Pittsburgh. We have Pittsburgh class B and several class D airspaces with good isolated distance. San Francisco area is covered by entwined class B, C, and D airspaces. It would take several flying with an instructor to be confident in such a complex airspace.
Detail of the flight is here.
|Comments are welcome. Send E-Mail to:|