In fact it's the same size we can find in the 3.30 fw (32 Ko decrypted)
Good behaviour at the moment.
Printable View
Sure, no problem. I'll check as well... Before you remove the mods though, make sure there are no active calls for the ms_write_log. I found that if I'm dumping to the ms, things tend to have hickups... ( not a real surprise )
In utils.c, there are simple error checkings only except for that for (i=1; i<5; i++) { line.
In graphics.c again, mostly error checkings except for the printTextScreen which I think is pretty obvious.
So, I don't see any major setbacks if you replace these, except the degree sign will not be shown...
I have been looking at the image memory allocation routines (those memaligns and associated linklists), I started tracking their allocs and frees and have some interesting results... More investigation is needed though, I haven't arrived to any conclusion yet, I want to understand the full process more... It seems that there is plenty of data not being free'd even if there is need for more. Except for that garbage_collection thread of course, which is not running quite frequently... I found problems mostly when you are changing zoom levels...
To Deniska
These my attempts to add Russian in the program...
but when i compile using make kxploit the program does not work with GPS and i don't understand why.. :confused:
http://files.filefront.com//;7329675;;/
coach777,
I did not have a chance to test the holux binary, but the PSP-290 one seems to works just fine...
Your make file for the holux build should look something like this:
TARGET = mapViewer
PSPSDK=$(shell psp-config --pspsdk-path)
PSPBIN = $(PSPSDK)/../bin
PSP_EBOOT_ICON = ICON0.PNG
PSP_EBOOT_PIC1 = PIC1.PNG
################################################## #################
#PSP-290/USB versionSPECIFIC DEFINITIONS::uncomment the lines below
################################################## #################
#BUILD_PRX = 1
#CFLAGS = -O2 -G0 -Wall -g -DDANZEFF_SCEGU -DNDEBUG
#LDFLAGS = -mno-crt0 -nostartfiles
#LIBS = -lpspdebug -lpsprtc -lpspgum -lpspgu -lpsppower -lpspusb -lpng -lz -ljpeg -lm -lc -lpspwlan -lmad -lpspaudiolib -lpspaudio -g
################################################## #################
#HOLUX GPSlim236+ version DEFINITIONS::uncomment the lines below
################################################## #################
CFLAGS = -O2 -G0 -Wall -g -DDANZEFF_SCEGU -DNDEBUG -DGENERIC
LIBS = -lpspdebug -lpsphprm_driver -lpsprtc -lpspvfpu -lpspgum -lpspgu -lpsppower -lpng -lz -ljpeg -lm -lpspwlan -lmad -lpspaudiolib -lpspaudio
OBJS = main.o \
graphics.o \
font.o \
utils.o \
attractions.o \
nmeap01.o \
danzeff.o \
NavigateCalculations.o \
sceUsbGps.o \
geo-client.o
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)
EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = mapViewer
include $(PSPSDK)/lib/build.mak
------------------------------------------------------
Make sure that you run holux build under 1.5 kernel and PSP-290 under 3.xx kernel...
If nothing else helps - try updating your PSPSDK with psptoolchain script
So will there be a lots of difference language in the next update?
I would gladly translate mapthis into Danish :-D
I went back to the generic version and has been testing it for like half an hour+ with several maps in huge/small ranges going crazy on zooming, moving etc. Never had any hangups... Can I have your dataset where you are experiencing problems?
( I am running 3.03OE-B in 1.5 mode. )
Yes, I'll try to throw in some generic localization bundle where users can specify their native character set and translate all "hardcodded" messages to their native tong...
It would look something like (short example of russian translation bundle):
#define your charset here
LOCAL_CHARSET=ÀÁÂÃÄŨÆÇÈÉÊËÌÍÎÏÐ ÑÒÓÔÕÖרÙÚÛÜÝÞß
#define your message translation here
::: HELP :::=::: ÏÎÌÎÙÜ :::
::: CONFIGURATION :::=::: ÊÎÍÔÈÃÓÐÀÖÈß :::
::: SELECT ACTION :::=::: ÂÛÁÅÐÈÒÅ ÄÅÉÑÒÂÈÅ :::
::: SELECT MAP :::=::: ÂÛÁÎÐ ÊÀÐÒÛ :::
The user will also need to generate the font for the local character set in a form of png file as show in the attachement...
Deniska why do you advice running PSP-290 on 3.x kernel ? Faster fixing is reported on 1.5 kernel mode by several users.
Also be aware to upgrade to 3.40OE-A.
Almost 70% of the files in Flash0 have been changed by $ony.
See here:
http://www.psp-hacks.com/forums/viewtopic.php?id=85249
I'm as you all know an experienced user of mapthis, but now my psp is messed up by upgrading from 3.10OE-A2 to 3.40OE-A. It seems that it has something to do with your psp region and flash1. I get the loading usb module error....?
Going to fix that first :(
I just upgraded to 3.40 OE and am happy to say that everything still works.
I did however fix my corrupted idstorage key a few weeks ago. Maybe it's a contributing factor.