After building our own project, I found that the textures.group.bin was not updated with the latest images. E.g if i were to compile today, the textures.group.bin still show the original date say 28/12/2009. Anyone face such problem?
Hello, I have a problem. Can`t build project for android after including s3eDialog.
Hi crosswind,
the .group.bin files on get made when you _run_ the app. The resource-building version of your app (which is x86 debug) will output these files as the relevant .group's are loaded.
Dave
soemtime happens to me that i forgive [RESMANAGER] ResBuild=0 in app.icf so it doesn't convert all resources.If you have this set change it to 1.
I am still confused about the workflow.
I have a data directory, in which I have a textures directory, which has my textures.group file.
When I run in debug mode on windows, it generated a textures.group.bin file in a different directory (called data-ram/data-gles1/textures). I'm confused. Why does the bin file get generated in data-ram. And if so, what should I have in the assets section of the mkb file? Should I have data/textures/textures.group or data-ram/data-gles1/textures/textures.group.bin. If the latter, then the build would fail because the bin file does not exist.
Basically, I'm just really confused. Can someone please explain in step by step detail what the correct user workflow is?
Hi Deadlineproof,
where exactly do you place the [RESMANAGER] ResBuild = 0.....you mean just place the parameters in the app.icf file?
Hi Dave P,
sorry I dnt realy get what you mean, can you explain?
Resmanager block goes in app.icf
in mkb in case of data/textures.group you have to use
assets
{
[default]
(data)
textures.group.bin
}
it then will search correct .bin file based on your resbuildstyle in the dataram dir.
In your case in the gles1 dir.
You can have different build styles.
For example if you use ResBuildStyle=gles1-pvrtc in app.icf you will have another dir with pvr compressed textures or you can define your own resbuild style.
This is needed to define different resources for different devices in the most complete way.
You can see the fighting game for an example of different resource builds.
Salman,
The issue here is that we try to provide examples that work with binary assets out of the box, that don't quite follow the normal workflow for binarisation and deployment.
The reason that files are written to data-ram is because the emulator by default mirrors a situation where the deployed files with your application aren't writable (the data directory) but these files can be shadowed with files written by your app (data-ram). See the s3eFile docs for details. It has the useful side-effect of meaning that all your binarised assets get written to data-ram, and that you can 'clean' your binarised assets by deleting data-ram.
So to answer your question, in the short term you want to do the following:
- change the mkb to using data-ram/data-gles1/textures/textures.group.bin for deployment assets. You may need to remove the 'strict' option from ExamplesCore.mkf to prevent any file-doesn't-exist warnings from stopping your project building. You always want to deploy the binary file (.bin) as the ARM build can't read non-binary assets (.group).
- Run the x86 debug build. This will generate textures.group.bin
- Build the ARM Release build and deploy the app to device.
The expected workflow for a larger project is to use a derbh archive. The assets section of the mkb specifies a derbh (.dz) file, and a .dcl script is made to produce a .dz file from all the binarised assets in data-ram. The kartz example shows how this is done - the dcl files are in data/derbhscripts and you can double-click them to generate the corresponding .dz files.
As the app is developed the dcl is run periodically (but not for every deployment) to generate known good sets of binarised assets.
crosswind, I think you have the same issue here - you want to change your mkb to take the binarised assets from data-ram.
If you put
[Resmanager]
Resbuild = 0
into your icf then the x86 debug build will NOT build resources, and will behave like an ARM build. Removing these lines or using Resbuild =1 will make it behave as normal.
I hope this helps
Dave
Hi Dave P,
this is what I have in my app.icf
# This file is for configuration settings for your
# application.
#
# The syntax is similar to windows .ini files ie
#
# [GroupName]
# Setting = Value
#
# Which can be read by your application using
# e.g s3eConfigGetString("GroupName", "Setting", string)
#
# All settings must be documented in .config.txt files.
# New settings specific to this application should be
# documented in app.config.txt
#
# Some conditional operations are also permitted, see the
# S3E documentation for details.
[S3E]
# Airplay can display a JPG splashscreen while the main application executable is loaded
# This will persist until the application first flushes the screen
SplashscreenBkR=255
SplashscreenBkG=255
SplashscreenBkB=255
Splashscreen=i3d_splash.jpg
SplashscreenWidth=160
SplashscreenHeight=100
[GX]
DataCacheSize=400000
Rasterisation=HW or SW
[Resmanager]
Resbuild = 1
I tried using both resbuild = 0 and resbuild = 1...but both doesnt seem to have any effects
and also my mkb file is taking assests from data-ram, below shows my mkb file
#!/usr/bin/env i3d_make_build.py
assets
{
[default]
(data)
i3d_splash.jpg
[artbuild]
(data)
.
(data-ram\data-gles1)
textures.group.bin
}
deployments
{
assets=default
[artbuild]
win32
assets=artbuild
}
subprojects
{
foodProj
iw2d
}
anyone able to help???
Hi crosswind,
Resbuild=1 is used when the X86 debug build runs. If this is set to true (or omitted entirely) the X86 debug application should definitely be building resources. Try searching for s3eFileOpen in your trace output to see where textures.group.bin is coming from. If you see your new resources in the application they must have been built to somewhere(!)
Assets are output to a directory reflecting their build style (e.g. assets optimised for the SW renderer are fairly different), which is why you see assets in data-ram/data-gles1.
The assets line is only used when you actually deploy to device. If you want to deploy the most recent version of the group.bin you need to point your mkb to it. Your mkb has the group.bin in the wrong asset section - it should be in the section following [default], it's currently in [artbuild] - but apart from that looks okay.
Let us know how it goes,
Mark.