Regarding two niftys, you could just use one:
-Make a normal layer for hud messaging.
-Make pause menu a popup. That should automagically disable all input for the underlying layers when dusplayed.
Hey wait, I think it would actually work better the other way around. The contacts menu and chat windows are pretty much popups by definition anyway.
Also I want to keep input for the underlying layers so I’m actually concerned about that. Do popups eat all inputs too?
Popups are made to eat all input… Maybe try making a regular layer with dynamic content for your nonblocking popup.
But I’m not sure if input is delivered to your ActionListeners though.
Hm, isn’t the standard jME shadow system cascaded PSSM too? I think I saw a way to tell jME how many slices it should make when generating the shadow map(s).
Soft shadows is a thing I would really like to see in the engine. Would be cool if they behave like in real life: The further away from the object casting the shadow, the bigger the relative area of penumbra on the ground / terrain / other objects.
→ Umbra, penumbra and antumbra - Wikipedia
2 Likes
Actually, I don’t think that there is a difference between PSSM and CSM. Why I am currently reinventing the wheel in JME has three reasons:
- I use deferred rendering (at least for sun light).
- Unlike any other materials in JME, I use a logarithmic depth buffer.
- In the future I would like to implement opacity shadow maps (OSM) to allow shadows from semitransparent volumes, i.e. clouds.
Thank you for the link to umbra (soft shadows explanation) @Ogli . This would be indeed a nice feature and if I implement it for my own system, I could also port it to the forward rendering pipeline of JME.
3 Likes
Well. Probably it is not very WIP screenshot. But I just laughed so hard at dat face, so I wanted to share 
. Cheer up sad people.
And the face of IMPOSSIBLE BRUTALITY in multiplayer:
It used as test model until I will find better model/modeler .
PS. It seems that game becomes quite big. If somebody interested in collaboration on online DND/RP with early medieval setting, we could have good time together.
5 Likes
So is it medieval setting (a realistic one) or does it contain magic, dragons, orcs and the like?
I plan on making a “medieval”+“fantasy” survival game and maybe at least the framework and the assets could be the same. Your plants and grass look nice. If it has a good page streaming (large world) I would be interesting.
Also I want to do research on certain medieval topics for that (how did they mine iron and make items, how did they make furniture, how did they make things like candles and clothes) so the crafting part will be realistic. Maybe I could share that in return.
But don’t rush. My stuff is a good idea but next two weeks will probably be invested in founding my startup company and publishing the OGF software here and on Github. I’ve got lots of things to do and need to focus on the important things first.
P.S. I LoLed at the face too, before I read the text I saw the picture. Made me laugh.
Early medieval in Europe, Dark Ages: feudals, inquisition, witches, attacks of muslim on Spain, viking attacks, tribalism and old gods, nomads from east. So it is realistic BUT game will allow influences of gods, curses, ghosts ( actions that may be regarded as luck or tale of a mad man).
Just google Dark Ages and look for some pictures. It is not very fantasy but very “survivalistic” 
Implemented. Map is not infinite, but huge. And it divided by chunks, loads dynamicly.
I support this idea, but in my humble opinion, people shouldn’t waste 4 hours just on making one sword and etc. Currently I implemended next craft system: You need to craft iron sword. At least you need iron, forge, anvil. And you feel free to create other part of recipe by yourself (and success of it depends on combination, perks and luck). It is in development of course.
When I will solve some issues with website, It would be much easier to show all planned/completed features.
Very well that you are interested. Good luck with your startup company!
Hey,
I mainly want to know about how they mined iron, melted it into blocks of steel - what buildings and tools were needed to make that: you can’t simply grab a piece of stone and hope there’s iron in it, then smash it with your hands and voila you have a block of steel which you can turn into a sword. You need a special oven, extract the iron. You need a rich source of iron - how did that look like (did they climb mountains and randomly collected rocks with certain structure or did they do it like in “Settlers” (part 1) and built mines with crane and elevators. Actually, the player will most certainly not do these basic things but buy the resources and then do some quick forging if the “smith skill” is high enough. Game will skip some virtual days by fast forwarding and you have your sword.
Something like that for all other things (clothes: collect plants or cut the hair of sheep and use the right tools to extract the strings, then use a wooden tool to turn that into fabric, then use another tool to turn that into clothes).
At least the tools should be accurate and must be aquired by the Player or an NPC in order to be able to make these things.
No punching trees but using a sawing mill.
Etc.
I understand you. It is interesting topic. Just keep in mind that not all people in medieval followed instructions
and
some of our ancestors really punched tree without using saw mill.
1 Like
So in playing around with Android Studio I found that my jME-TrueTypeFont library doesn’t work on Android because java.awt.Font is not available on Android devices. I’ve been working on a solution using Google’s Sfntly library so when jME-TrueTypeFont is used on Android it uses Sfntly instead of awt. Still plenty of tuning to do but here’s an atlas I generated:
Sfntly doesn’t actually do any processing on a true type font file like awt, it just provides the raw data so glyphs are looked up via the cmap, loca and glyf tables then the curves are parsed out to android.graphics.Path objects and drawn to an android.graphics.bitmap which is then converted to a Texture.
Sfntly is pretty nice actually, gives me direct access to the data so I can grab exactly what I need how I need it. Unfortunately Android’s Typeface and Paint classes don’t provide the necessary information about a glyph for use in this capacity, actually they don’t really seem to provide any information at all about individual glyphs which is where Sfntly comes in 
5 Likes
Again thanks a lot for your effort. btw, it seems in Android N the java.awt.font package will be available.
Interesting article, but it doesn’t say anything about java.awt.Font. Google had been using Oracle’s proprietary java development kit for Android and removed a few things from it such as java.awt.Font. I don’t think switching to OpenJDK will change anything in that regards. The latest Android Studio Beta I’m using is, I think, bundled with OpenJDK.
Not that makes a whole Lotta difference, I’m compiling with Oracle’s proprietary JDK8 and the emulator throws a VerifyError when trying to access anything java.awt.Font related.
Apparently a VerifyError happens when your app is running with different versions of libraries than it was compiled against. In other words the compiler didn’t catch the issue with java.awt.Font, but at runtime the class was not present.
Ah, hope i am not wrong but doesn’t this sentence from above link
Use openjdk classes from java.awt.font package.
indicate that. Or i may understand it wrong?
I might get this wrong. So sorry if it is irrelevant .
Hey Tryder,
good to know it’s now on Android too. Is your ttf renderer still partially using GPL software or did you find a more open library for the algorithm in the meantime? Thanks,
FYI
I’m currently working on “FontLib” and “TextBox” in my “GameFont” package - they’re my abstract base classes/interfaces that will encapsulate any Font or Text (not just BitmapFont or BitmapText but also my new BitmapFont2, BitmapText2, some 3D-Glyphs and hopefully Tryder-TTF too). :chimpanzee_closedlaugh:
1 Like
I skipped over that line, but still won’t be relevant for 5 or so years since no current Android device supports it and if a few devices are released soon that support it then you run into the fact that 99.9% of devices don’t.
@Ogli jME-TrueTypeFont doesn’t depend on any GPL libraries, only jME-TrueTypeFont3D does.
Really what’s nice about this on Android is that you can detect the screen density at runtime and scale your point sizes accordingly so that fonts stay roughly the same physical size across devices. The font in that picture is 64 point, which on my computer would be quite big. A 16 point font might look nice on a ldpi device, but barely visible on an hdpi device.
Yes, I know this problem with the pixel density. Two or so years ago I decided that there must be a popup showing three different text labels to a PC user and the user will pick one of them when game starts for the first time ever. There are some high resolution displays for PC too (I think there is a Mac that has higher dpi).
I hope that VR goggles will support that too (currently it’s like with gaming consoles - there are 2 or 3 standard devices and you can look up resolution data on the internet). Hope that companies will be relaxed enough to agree on an industry-wide standard for that problem.
Good to know that on Android this is almost no problem at all.
One problem always remains though: Some people with impaired vision need bigger font sizes.
And small texts and poorly written apps drive me nutzzz… :chimpanzee_closedlaugh:
Amen.
I’m on the threshold of needing glasses (well, probably over the threshold but I’m stubborn) and some games are just crazy with the small font sizes. And when I’m complaining about that on an 8 ft screen that’s a problem. (To play FF XIV on PS4, I actually slid the couch closer to the screen because of the crazy small fonts.)
Why should a font size in “points” be different on different DPI? Point is not pixel. Point is 1/72nd of an inch. So, no matter the DPI, it should be 1/72nd of an inch.
The calculation for a point size is (pointSize * screenDensity) / ( 72 * unitsPerEm). UnitsPerEm depends on the font, it is a setting made by the font designer, screen density is the number of pixels per inch on the screen displaying the text and point size is the value entered by the user. So this calculation is made when the font is loaded and displayed. When you create a bitmap font this calculation is done based on your monitors screen density and the point size you requested, when that bitmap font is displayed on someone elses monitor it does not conform to their screen’s density and will therefore be bigger or smaller than 1/72 of an inch per point.
For instance say you want to make an Android game and on your development computer you make a bitmap font and in this bitmap font the letter A is 16 pixels tall. On your mobile it will also be 16 pixels tall, but your mobile has a smaller screen with more densely packed pixels so 16 pixels takes up significantly less physical space. The font might be legible on your computer, but illegible on a cell phone.
Then consider that Android devices come in a wide range of screen sizes and densities. You might have a 7 inch screen at 800x400 or a 5 inch screen at 1920x1080. So your bitmap font is going to be illegible on the 5" screen, but kinda big on the 7" screen. To address this issue you scale the font based on the screens density, but with bitmap fonts this results in aliasing which looks bad, even terrible. When you create the font’s texture atlas at runtime you alleviate the issue because you create a font that is custom fit for the platform running it.
Of course then you need a GUI system that can scale dynamically.
1 Like